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PREFACE 

This  technical  report  describes  Phase  One  of  a project  to  convert 
the  BALFRAM  computer  program  from  a batch-oriented  program  to  an  inter- 
active program.  Interactive  means  that  the  decision  maker  or  other  model 
user  can  communicate  directly  with  the  model  as  it  executes  on  the  computer 
and  examine  and  manipulate  decision  parameters  to  directly  control  the 
problem  solution.  This  report  presents  the  technical  details  of  the  modi- 
fications made  during  this  model  revision  phase;  this  report  is  not  in- 
tended to  present  a complete  description  of  the  operation  and  use  of 
BALFRAM.  For  complete  documentation  on  BALFRAM,  readers  are  referred 
to  the  following  documents: 

E.  H.  Means,  C.  L.  Phillips,  and  S.  E.  Young,  BALFRAM  User  Manual 
for  the  Staff  of  the  Commander  In  Chief  Pacific.  Stanford  Research 


Institute,  Menlo  Park,  CA  94025,  Technical  Note  NWRC-TN-52  (Septem- 
ber 1974). 

0.  F.  Forsyth,  C,  L.  Phillips,  and  S.  E.  Young,  BALFRAM  Program 
Maintenance  Manual  for  the  Staff  of  the  Commander  in  Chief  Pacific, 


Stanford  Research  Institute,  Menlo  Park,  CA  94025,  Technical  Note 
NWRC-TN-53  (December  1974), 

E.  H.  Means,  BALFRAM  Seminar  Guide,  Volumes  I and  II,  Stanford 
Research  Institute,  Menlo  Park,  CA  94025,  Technical  Note  NWRC-TN-63 
(February  1976). 
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1.1  BACKGROUND 

BALFRAM  is  a computer  model  used  in  planning  and  analysis  studies 
for  investigating  military  force  interactions.  The  BALFRAM  technique 
uses  specially  designed  input  descriptions  of  military  interactions  to 
construct  a computer  model  tailored  to  a military  situation  or  scenario. 
These  input  commands  permit  the  military  situation  to  be  described  from 
the  perspective  of,  and  in  the  terminology  of,  the  military  planner. 

Using  this  technique,  a planner  can:  analyze  combinations  of  land,  sea, 
and  air  force  levels;  analyze  capabilities,  deployments,  and  employment 
strategies  required  to  achieve  a desired  outcome;  and  estimate  the  ef- 
fectiveness of  available  forces  in  carrying  out  given  operational  plans. 

BALFRAM  has  evolved  over  the  past  decade  through  a research  and 
development  program  sponsored  by  the  Office  of  Naval  Research  (ONR). 
Partial  support  for  the  program  has  been  provided  by  the  Commander  in 
Chief  Pacific  (CINCPAC)  in  recognition  of  BALFRAM' s continuing  value  to 
the  planning  function  of  that  headquarters.  BALFRAM  computer  programs 
have  been  implemented  on  the  World  Wide  Military  Command  and  Control 
System  (WWMCCS)  computer  at  CINCPAC,  BALFRAM  is  also  in  use  at:  Head- 
quarters, Pacific  Air  Forces;  the  U. S. -Taiwan  Defense  Command;  the 
Ministry  of  National  Defense  of  the  Republic  of  China;  and  the  U. S. 

Naval  Surface  Weapons  Center.  The  BALFRAM  methodology  is  now  being 
transferred  to  the  U.  S. /ROK  Operational  Planning  Staff,  U. S.  Forces 
Korea.  In  addition  BALFRAM  has  been  used  in  studies  performed  for  the 
Chief  of  Naval  Operations  (OP-60  and  OP-96) , CINCPACFLT,  and  Headquarters 
Marine  Corps. 

The  potential  use  of  BALFRAM  by  various  Naval  and  other  service 
commands  is  expected  to  increase.  However,  because  of  the  evolutionary 
nature  of  the  development  of  BALFRAM  methodology  and  the  batch-processing 
orientation  of  the  model,  restructuring  work  was  done  during  this  research 
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to  enhance  the  basic  BALFRAM  concept  and  to  make  it  a more  effective  l! 

j 

and  responsive  tool  for  military  decision  makers.  ji 

I ' 
i i 

!i 

1.2  THE  C(»JCEPT  OF  AN  INTERACTIVE  BALFRAM  H 

i 

The  idea  of  an  interactive  BALFRAM  program  has  existed  for  some 

time.  The  proposed  ultimate  BALFRAM  program  is  a CRT-oriented  process  i 

i 

whereby  the  decision  makers  or  analysts  can  interact  with  the  computer  ' 

dynamically  by  using  on-line  terminals.  ' 

The  conventional  method  of  computer-aided  modeling  is  essentially 
a batch  process,  which  does  not  adequately  meet  the  needs  of  decision 
makers.  All  the  parameters  and  decision  rules  must  be  specified  before 
the  model  is  run.  The  user  has  no  knowledge  of  the  interim  results  while 
the  model  is  executing  and  therefore  cannot  terminate  computer  processing 
if  his  objective  has  been  achieved  of  if  the  processing  has  become  un- 
stable. Once  computer  processing  begins,  the  user  cannot  change  param- 
eters to  facilitate  convergence  of  the  problem  or  study  alternatives 
that  might  become  evident  during  the  processing.  Such  alternatives  may 
not  be  evident  in  the  masses  of  printed  output  currently  generated. 

These  disadvantages  result  in  "middlemen"  (analysts,  programmers,  data 
aides)  being  interposed  between  the  decision  maker  and  the  model.  The 
result  is  a long  reaction  time  between  the  user's  decision  and  the  model 
feedback. 

In  the  context  of  computerized  wargaming,  "interactive  process"  con- 
notes a model  that  is  dynamically  responsive  to  the  decision  maker.  It 
implies  that  the  decision  maker  can  communicate  with  the  executing  model 
during  problem  solving  and  options  analysis.  The  decision  maker  can 
examine  and  manipulate  various  aspects  of  his  decision  parameters  to 
control  the  process  of  problem  convergence. 

Because  of  the  shortened  cycle  time  and  increased  system  responsive- 
ness, the  decision  makers  will  take  greater  advantage  of  an  interactive 
computer-aided  model  as  a decision  tool.  The  added  flexibility  and  feed- 
back capabilities  make  convergence  to  an  optimal  set  of  solutions  more 
probable.  The  decision  maker  gains  greater  understanding  of  his  problem  ' 
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and  the  parameter  interrelationships  through  model  manipulation.  More 
subtle  and  complex  judgments  that  defy  computer  algorithms  can  be  in- 
cluded to  more  realistically  represent  the  real  world. 

1.3  PHASE  ONE--MODEL  REVISION 

ONR  and  CINCPAC  funded  this  research  program  for  the  purpose  of 
developing  an  interactive  BALFRAM.  However,  current  users  of  BALFRAM 
(especially  CINCPAC)  have,  over  the  years  since  BALFRAM  was  installed, 
accumulated  requirements  for  modifications  to  the  batch  version  of 
BALFRAM.  Because  these  modifications  affect  the  utility  of  BALFRAM  for 
operational  commands  and  because  interactive  BALFRAM  could  not  be  fully 
implemented  immediately,  this  research  program  was  directed  toward  the 
needed  modifications  and  other  preparations  for  interactive  BALFRAM. 

The  desired  modifications  can  be  divided  into  two  classes.  Struc- 
tural modifications  were  made  to  remove  superfluous  routines  that  had 
been  superceded  and  to  restructure  the  remaining  routines  into  new 
execution  modules  that  would  be  more  compact  in  memory.  The  second 
class  of  modifications  improved  the  utility  of  certain  descriptors  that 
controlled  the  progress  of  the  force  interactions.  New  and  changed 
capabilities  were  desired  that  would  make  describing  military  scenarios 
and  force  interactions  more  efficient. 

A second  objective  of  the  research  described  in  this  report  was  to 
improve  the  documentation  of  the  BALFRAM  programs  in  preparation  for  the 
major  changes  that  would  take  place  during  the  design  and  implementation 
of  interactive  BALFRAM.  Changes  made  to  the  model  software  prior  to  and 
during  this  research  needed  to  be  adequately  documented,  and  the  documen- 
tation needed  to  be  brought  up  to  date.  This  new  documentation  would  be 
useful  not  only  for  the  interactive  systems  design,  but  also  for  all  the 
other  current  users  of  BALFRAM. 

1.4  REPORT  ORGANIZATION 

The  desired  model  modifications  have  been  made  and  are  described  in 
this  report.  Section  2 discusses  three  areas  of  BALFRAM  modifications. 
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The  major  modifications  to  the  parameter  change  card  (PARMCHNG)  are 
discussed  first.  Changes  to  the  other  descriptors  and  to  the  program 
control  card  and  user  interface  are  then  discussed.  Section  3 is  a dis- 
cussion of  the  software  documentation  and  introduction  to  the  Individual 
parts  of  the  program  documentation.  Because  of  the  large  volume  of  docu- 
mentation, some  material  is  included  as  appendices  rather  than  within 
Section  3. 

Two  of  the  appendices  need  special  note.  This  technical  report  is 
written  with  the  assumption  that  the  reader  is  familiar  with  BALFRAM, 
especially  the  use  and  functioning  of  the  BALFRAM  input  cards  (called 
descriptors).  For  readers  unfamiliar  with  the  descriptors,  Appendix  D 
provides  a brief  overview  of  the  purpose  of  each  descriptor. 

Dr.  Paul  Tuan  presented  a paper  at  the  Theater-Level  Gaming  Con- 
ference in  Washington,  D.C.  in  September  1977.  His  paper,  entitled 
"Some  Tactical  Problems  in  Man/Computer  Interactive  Gaming,"  centered 
around  BALFRAM,  and  is  included  with  the  accompanying  illustrations  in 
this  report  as  Appendix  E. 


2.  BALFRAM  PROGRAM  REVISIONS 


2.1  INTRODUCTION 

BALFRAM  has  been  used  for  military  studies  and  planning  since  the 
early  1970s  by  several  major  military  commands.  During  this  time, 
analysts  have  defined  revisions  that  would  make  BALFRAM  easier  to  apply 
to  typical  military  problems  or  that  would  enhance  the  user  interface 
through  revised  inputs  and  outputs.  The  task  work  reported  here  is  the 
first  task  in  a logical  progression  leading  to  an  interactive  BALFRAM. 
These  changes  represent  a beginning  of  the  updating  process. 

Because  BALFRAM  is  a large,  complex  model  being  used  in  several 
commands,  the  change  process  proceeded  in  a conservative,  methodical 
way.  Because  the  changed  program  would  be  converted  to  other  computers, 
ANSI  standard  FORTRAN  was  followed.  FORTRAN  statements  unique  to  a 
particular  computer  were  avoided  as  an  impediment  to  transferability. 
When  converting  the  original  BALFRAM  to  the  SRI  GDC  6400  computer,  the 
changes  were  made  in  a form  that  would  require  little  or  no  conversion 
effort  when  transferring  back  to  the  Honeywell  WWMGGS  computer.  The 
software  improvements  also  were  implemented  in  standard  FORTRAN  with 
liberal  use  of  comments. 

Where  new  capabilities  were  added  to  old  BALFRAM  descriptors  or 
where  new  descriptors  were  added,  existing  BALFRAM  input  formats  were 
followed  as  closely  as  possible.  All  the  original  BALFRAM  descriptor 
cards  continue  to  function  as  described  in  BALFRAM  User  Manual  so  that 
existing  data  decks  can  be  used  as  they  are,  with  the  improved  program. 
BALFRAM  users  can  incorporate  the  improvements  without  a major  training 
process  or  disruptions  of  existing  uses  of  the  model.  With  this  ap- 
proach, there  was  no  need  to  make  major  changes  to  the  input  routines-- 
a job  that  would  have  to  be  redone  during  the  design  and  implementation 
of  the  interactive  version  of  BALFRAM. 
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Software  changes  were  designed  to  minimize  the  memory  and  execution 
time  required.  New  functions  were  added  to  existing  descriptors  rather 
than  defining  new  descriptors  and  new  variables.  Changes  were  made  to 
allow  as  much  processing  as  possible  outside  the  innermost  loop  of  sub- 
routine TSMO,  where  event  and  time  updates  occur  during  the  progression 
of  simulated  time. 

Design  and  program  coding  of  any  changes  were  done  in  a straight- 
forward manner.  Unusual  methods  that  might  save  minor  amounts  of  memory 
or  execution  time  (such  as  word  packing  or  complex  FORTRAN  programming) 
were  avoided  in  the  interest  of  program  comprehension  and  maintainability. 

A series  of  subtasks  were  specified  in  the  SRI  proposal  and  contract. 
Additional  changes  were  made  as  they  were  required.  For  clarity  of  dis- 
cussion, these  changes  can  be  organized  into  the  following  areas: 

• The  PARMCHNG  descriptor 

• Other  descriptors 

• Program  control  and  user  interface. 

2.2  PARMCHNG  DESCRIPTOR  IMPROVEMENTS 
2. 2. 1 Background  Leading  to  Improvements 

The  PARMCHNG  (parameter  change)  descriptor  resets  input  parameter 
values  at  a specified  time  during  a BALFRAM  scenario.  This  descriptor 
card  specifies  the  unit  and  parameter  that  is  to  be  changed  and  provides 
the  new  parameter  value  and  the  time  this  new  value  is  to  take  effect. 
Several  changes  were  needed  to  improve  the  utility  of  this  card. 

The  original  PARMCHNG  card  specified  only  one  unit,  one  parameter, 
and  one  effective  time.  However,  typical  scenarios  might  require  the 
same  parameter  be  changed  for  several  units  at  the  same  time  or  several 
parameters  changed  for  one  unit  at  once.  These  situations  required  a 
multiple  of  almost  identical  PARMCHNG  cards,  making  the  input  cumbersome 
to  assemble. 

During  sensitivity  studies,  RANDMSEQ  and  FRCRATIO  cards  often  vary 
the  same  parameters  that  are  changed  by  PARMCHNG  cards.  The  RANIWSEQ 
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and  FRCRATIO  cards  affect  the  Initial  game  conditions  according  to  the 
input  instructions.  The  PARMCHNG  card  replaces  parameter  values  during 
the  play  of  the  game.  In  choosing  PARMCHNG  values,  the  analyst  usually 
relates  the  new  value  to  the  initial  value  of  the  parameter  so  that  the 
new  value  is  proportional  to  the  initial  value.  Although  the  RANDMSEQ 
and  FRCRATIO  cards  would  scale  the  initial  values,  they  would  not  scale 
the  new  values  on  the  PARMCHNG  card,  thereby  destroying  the  proportion 
between  the  initial  conditions  and  the  updated  conditions.  This  caused 
inaccuracies  in  the  sensitivity  runs,  reducing  the  value  of  automatic 
generation  of  sensitivity  studies. 

The  variables  to  be  changed  by  the  PARMCHNG  cards  are  identified 
by  a code  that  can  specify  nine  variables,  primarily  variables  on  the 
UNITSPEC  card.  Use  of  the  BALFRAM  model  in  typical  analytical  situations 
indicated  that  additional  variables  should  be  able  to  be  changed.  These 
included  variables  on  the  NODEPROP  card,  which  cannot  be  changed  at  all 
in  the  original  mode.  These  additions  would  provide  more  flexibility 
in  describing  the  complexities  of  military  situations. 

2.2.2  Change  to  Permit  Multiple  Unit  References 
on  a PARMCHNG  Card 

To  accommodate  multiple  changes  on  one  PARMCHNG  card,  three  new 
descriptor  cards  were  implemented.  These  new  cards  describe  three  types 
of  multiple  change  situations.  Table  1 compares  the  number  of  units, 
parameter  codes,  and  parameter  values  per  card  of  the  original  PARMCHNG 
descriptor  cards  with  the  capabilities  of  the  three  added  descriptor 
cards:  PVCHANGE,  UVCHANGE,  and  UNCHANGE.  The  PVCHANGE  descriptor  card 
permits  changing  up  to  four  parameters  for  a specific  unit.  The  UVCHANGE 
descriptor  card  permits  changing  the  same  variable  code  for  up  to  four 
different  units  by  providing  a new  parameter  value  for  each  of  the  four 
units.  The  UNCHANGE  descriptor  card  is  similar  to  the  UVCHANGE  descrip- 
tor except  that  a single  parameter  is  changed  to  a given  value,  but  it 
can  be  changed  for  up  to  ten  units  with  the  one  input  card.  The  descrip- 
tor names  refer  to  the  fields  changed.  PVCHANGE  changes  multiple  Param- 
eter codes  and  Values;  UVCHANGE  changes  multiple  Units  and  Values;  and 
UNCHANGE  changes  multiple  UNits. 


Table  1 


CAPABILITIES  OF  NEW  PARMCHNG  DESCRIPTORS 
(Table  entry  is  the  number  of  descriptor  fields  entered  on  one  card) 


Descriptor 

Name 

Descriptor  Field 

Effective 

Time 

Unit 

Identification 

Parameter 

Code 

New  Parameter 
Value 

PARMCHNG 

Single 

Single 

Single 

Single 

PVCHANGE 

Single 

Single 

4 

Maximum 

4 

Maximum 

UVCHANGE 

Single 

4 

Maximum 

Single 

4 

Maximum 

UNCHANGE 

Single 

10 

Maximum 

Single 

Single 

Depending  on  the  scenario  updates  to  be  made,  each  new  descriptor 
can  save  from  three  to  nine  cards  in  the  input  files.  For  example,  if 
10  aircraft  units  (squadrons,  for  example)  were  to  be  augmented  with  four 
aircraft  each  30  days  after  the  start  of  the  scenario,  a single  UNCHANGE 
card  could  be  used  to  describe  the  situation  instead  of  the  ten  PARMCHNG 
cards  previously  required.  If  the  squadrons,  however,  were  to  be  augmented 
with  differing  number  of  aircraft  per  squadron,  then  the  UVCHANGE  card 
would  be  used  where  the  unit  identifier  for  each  squadron  and  the  number 
of  aircraft  augmented  for  that  squadron  would  be  entered  for  up  to  four 
squadrons  per  card. 

The  FORTRAN  program  changes  that  implement  the  new  descriptors  effect 
only  the  input  processing.  During  the  input  edit  processing,  the  multiple 
values  on  the  new  descriptors  are  expanded  to  a series  of  equivalent  single 
PARMCHNG  cards.  The  reordering  by  time  of  parameter  changes  in  subroutine 
MINV  and  the  updating  of  the  PARMCHNG  values  during  the  play  of  the  battle 
scenarios  in  subroutine  ADCP5  remain  the  same.  The  maximum  limit  of  100 
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parameter  changes  is  also  retained.  Software  changes  are  only  necessary 
in  subroutine  INPUTS  and  do  not  add  memory  or  processing  requirements  to 
the  critical  overlays  in  the  actual  battle  processing. 

The  new  card  formats  and  data  formatting  instructions  are  included 
in  Appendix  A.  These  instructions  should  be  added  to  the  BALFRAM  User 
Manual  after  the  discussion  of  the  PARMCHNG  descriptor.  The  card  formats 
have  been  designed  to  adhere  to  the  BALFRAM  standard  of  five-and- ten-column 
field  definitions  (although  unit  identifiers  are  generally  three  columns 
wide) . 

2.2.3  Additional  New  PARMCHNG  Variable  Codes 

To  extend  the  PARMCHNG  card  capability,  four  new  variable  codes  were 
added  to  permit  changing  parameters  found  on  the  NODEPROP  card.  All  fields 
on  the  NODEPROP  descriptor  were  examined  and  only  four  fields  were  found 
appropriate  to  change  by  means  of  the  PARMCHNG  descriptor.  The  major 
NODEPROP  fields  not  changed  are  the  exogeneous  firepower  and  time  values. 
The  NODEPROP  exogeneous  firepower  effectiveness  and  its  associated  fields 
(scaling  factor  and  fraction  of  order  of  battle  to  generate  exogeneous 
firepower)  can  already  be  changed  by  code  2 on  the  PARMCHNG  descriptor 
card.  The  NODEPROP  time  values  were  not  included  because  of  the  inter- 
acting effects  of  multiple  time  changes  and  the  possibilities  of  difficult 
contingency  logic  debugging  when  time  changes  occur  in  more  than  one  place. 

The  new  values  of  the  parameter  change  codes  are  shown  in  Table  2. 

The  first  nine  codes  are  the  same  as  the  existing  codes;  the  last  four 
(numbers  10  through  13)  are  the  newly  added  NODPEPROP  variable  codes. 

Table  2 provides  the  new  code  values  as  well  as  referencing  the  descriptor 
and  field  location  where  the  complete  variable  definition  can  be  found 
in  the  User  Manual.  These  new  codes  are  to  be  used  on  the  PARMCHNG, 
PVCHANGE,  UVCHANGE,  and  the  UNCHANGE  descriptors. 

The  new  variable  codes  were  implemented  in  subroutine  ADCP5,  where 
the  PARMCHNG  processing  is  accomplished  during  the  scenario  play.  New 
FORTRAN  statements  were  added  for  processing  codes  9 through  13  and  a 
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Table  2 

REVISED  PARMCHNG  VARIABLE  CODES 


Variable  Definition 

Variable 

Definition  Reference 

Descriptor 

Card 

Field 

Number 

Increment  to  unit  order  of  battle 

Not  used 

UNITS PEC 

5 

Index  of  Combat  Effectiveness  (ICE) 

UNITS PEC 

8 

Mobility  factor 

UNITS PEC 

10 

Nodal  objective  of  unit 

Not  used 

UNITSPEC 

12 

Exogenous  firepower  target  node 

UNITS PEC 

13 

Disengagement  code 

GUERILLA 

5,7,9,.,. 

Defeat  criterion  (actual  order  of 
battle  - not  percent) 

UNITS PEC 

7 

Nodal  location  of  units  used  to  compute 
exogenous  firepower 

NODE PROP 

4 

Target  node  for  exogenous  firepower 

NODE PROP 

5 

An  additional  node  whose  use  is 
determined  by  the  code  supplied  in 
field  7 - NODE PROP 

NODE PROP 

6 

Exogenous  firepower  computation  code 

NODE PROP 

7 

branch  was  inserted  into  the  existing  code  to  transfer  to  the  new  section 
if  the  code  value  was  greater  than  9.  This  change  permitted  implementa- 
tion without  substantial  reprogramming  of  subroutine  ADCP5. 
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2.2.4  PARMCHNG  Adiustment  to  Variables  Affected  by  FRCRATIO  and  RANDMSE< 


To  properly  scale  PARMCHNG  variables  for  sensitivity  studies,  new 
FORTRAN  programming  was  inserted  to  save  the  values  input  on  the  PARMCHNG 
cards  for  subsequent  scaling  by  FRCRATIO  and  RANDMSEQ  processing.  Since 
initial  conditions  are  already  saved  twice  (after  input  has  been  read  and 
edited  and  after  FRCRATIO  and  DSTRIBUT  variations  are  applied  to  the  data), 
the  PARMCHNG  data  could  be  saved  on  the  same  files.  Thus,  the  initial 
PARMCHNG  conditions  could  be  retained  the  same  as  the  other  program  data 
even  after  scaling  by  the  FRCRATIO  and  RANDMSEQ  parameters. 

Scaling  PARMCHNG  values  is  required  during  FRCRATIO  processing  in 
subroutine  SURFGN  and  during  RANDMSEQ  processing  in  subroutine  RANDM.  In 
both  places,  PARMCHNG  scaling  is  required  only  when  identical  variables 
from  the  identical  units  matched.  Although  identical  variables  are  changed 
by  PARMCHNG,  FRCRATIO,  and  RANDMSEQ  descriptors,  each  descriptor  used  a 
different  variable  code  to  identify  variables.  To  efficiently  match 
identical  variables,  two  translation  tables  were  constructed  for  converting 
the  FRCRATIO  and  RANDMDEQ  variable  codes  to  the  equivalent  PARMCHNG  code. 
These  tables  (in  arrays  IFR2PC  and  IRS2PC)  were  built  into  subroutines 
SURFGN  (for  FRCRATIO)  and  subroutine  RANDM  (for  RANDMSEQ). 

The  general  procedure  for  PARMCHNG  scaling  is  the  same  for  both 
FRCRATIO  and  RANDMSEQ  processing.  After  computing  FRCRATIO  and  RANDMSEQ 
scaling  factors,  all  PARMCHNG  cards  are  checked  for  a match  on  unit  iden- 
tifier and  PARMCHNG  variable  code.  When  this  match  occurs,  the  scaling 
factor  is  applied  to  the  PARMCHNG  new  value.  The  scaling  factors  are  then 
applied  to  the  variables  specified  on  the  FRCTATIO  or  RANDMSEQ  cards.  As 
BALFRAM  loops  through  variations  in  sensitivity  studies,  PARMCHNG  variables 
are  automatically  reset  to  initial  conditions  with  the  other  program  data 
by  being  read  from  the  appropriate  files.  This  method  requires  additional 
processing  during  the  initial  phase  of  each  sensitivity  run  rather  than 
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in  the  game  simulation  loop  during  the  play  of  a particular  variation. 
Such  placement  saves  execution  time  by  minimizing  calculations  in  the 
innermost  loops  of  the  game-play  subroutines. 
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While  subroutine  RANDMN  was  being  improved  with  the  new  PARMCHNG 
programming,  the  format  of  the  summary  data  that  are  printed  was  also 
changed  to  print  more  information  and  to  label  the  printed  information 
more  descriptively. 

2.3  CHANGES  TO  OTHER  DESCRIPTORS 

In  addition  to  the  major  changes  in  the  PARMCHNG  descriptor,  other 
improvements  increased  the  capabilities  of  or  added  functions  to  other 
BALFRAM  descriptors.  These  improvements  expanded  BALFRAM  capability  for 
describing  typical  military  situations.  This  section  describes  these 
changes. 

2.3.1  UNITSPEC  Descriptor  Sortie  Rate 

i 

Some  units  in  a military  scenario  have  attrition  expressed  on  a | 

per  sortie  basis.  An  example  is  an  aircraft  squadron  where  attrition  is  | 

measured  on  a sortie  basis--one  aircraft  performing  one  mission.  The 

individual  equipment  might  perform  one  mission  more  or  less  than  once  per  ' 

day  depending  on  the  scenario  and  equipment  capability.  Aircraft  could  < 

fly  1.5  sorties  per  day  on  the  average  (3  sorties  every  2 days)  or  0.5  ' 

sorties  per  day  (1  sortie  every  other  day).  In  assembling  data  for 

equipment  with  sortie  rates  different  than  1.0,  the  analyst  would  have  j 

to  multiply  the  equipment  inventory  by  the  sortie  rate  for  input  as  the  | 

order  of  battle.  Handling  data  this  way,  however,  obscures  the  quantity 
of  equipment  available  and  the  sortie  rate. 

BALFRAM  was  changed  to  make  the  sortie  rate  an  explicit  input  on  the 
UNITSPEC  card  in  place  of  a variable  no  longer  used.  During  input  editing 
in  subroutine  INPUT,  sortie  rate  (i.e.,  missions  per  time  unit)  and  order 
of  battle  (now  interpreted  as  on-hand  equipment)  are  multiplied  to  give 
the  order  of  battle  for  simulation  play.  When  sortie  rate  is  not  appli- 
cable, 1.0  is  entered  so  the  order  of  battle  remains  as  specified  on  the 
UNITSPEC  card.  i 
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2.3.2  Increased  Units  on  LGINTDIC  and  SUMUNIT  Descriptors 

As  experience  was  gained  with  BALFRAM,  it  was  found  that  the  number 
of  units  specified  on  the  LGINTDIC  and  SUMUNIT  descriptors  were  inadequate 
to  describe  scenarios  modelled.  This  situation  was  remedied  by  increasing 
the  size  of  the  arrays  for  storing  the  unit  identifiers.  In  addition, 
parameters  controlling  the  input  editing  of  these  descriptors  were  ad- 
justed to  indicate  the  increase  of  units  from  10  to  20.  The  input  READ 
statement  also  had  to  be  adjusted  to  allow  a second  data  card  if  required. 
No  changes  were  required  in  subroutines  ADCP4  or  ADCP7  where  the  LGINTDIC 
and  SUMUNIT  parameters  are  processed  because  this  processing  is  controlled 
by  indexes  constructed  during  input  editing. 

2.3.3  New  STOPBTLE  Descriptor  Functions 

The  only  method  to  stop  the  simulation  play  in  the  original  BALFRAM 
model  was  based  on  the  destruction  of  all  units  on  an  input  list.  Exten- 
sive use  of  BALFRAM  indicated  that  other  criteria  based  on  time  and  unit 
objectives  would  be  useful  for  stopping  the  battles.  Thus,  two  more 
criteria  have  been  added--stopping  when  the  duration  of  the  battle  reaches 
a predefined  time  and  stopping  when  any  one  of  a list  of  units  reaches 
its  final  objective. 

Rather  than  introduce  new  descriptor  cards,  the  STOPBTLE  card  was 
modified  to  accommodate  these  two  new  functions  along  with  the  function 
it  already  performs.  The  first  unit  in  the  list  of  units  on  the  STOPBTLE 
card  is  now  used  as  a code  value.  If  this  unit  is  positive,  the  STOPBTLE 
card  processes  as  it  always  has.  If  the  field  for  the  first  unit  contains 
i -1,  the  field  for  the  second  unit  is  interpreted  as  the  time  to  end  the 

battle.  If  the  field  for  the  first  unit  contains  -2,  the  battle  is 
stopped  if  any  unit  in  the  list  of  units  has  reached  its  final  objective. 
New  programming  was  added  to  subroutine  ADCP  to  process  the  new  forms  of 
STOPBTLE  and  to  subroutine  SHFREF  to  eliminate  the  internal  unit  identifier 
conversion. 

Appendix  A contains  descriptions  of  the  new  functions  of  the  STOPBTLE 
card  for  insertion  into  the  appropriate  place  in  the  BALFRAM  User  Manual. 


13 


r 


2.3.4  Added  PROASIGN  Descriptor  Function 

The  original  PROASIGN  descriptor  redistributed  the  total  surviving 
order  of  battle  of  a set  of  units  back  among  those  units  according  to 
input  apportionment  factors.  These  factors  could  be  changed  as  a func- 
tion of  time.  As  complex  scenarios  were  developed,  a new  requirement  was 
evident.  The  order  of  battle  to  be  apportioned  could  be  a function  of 

the  remaining  order  of  battle  of  another  unit  upon  whom  the  list  of  units  ! 

i 

were  dependent.  Such  a case  might  be  the  air  wings  on  a carrier.  As  the  ■ 

carrier  is  damaged,  two  effects  occur:  aircraft  on  board  the  carrier  are 
also  damaged,  and  the  capacity  of  the  carrier  to  launch  the  recover  air- 
craft is  diminished  so  that  all  the  undamaged  aircraft  on  board  cannot 
be  launched.  To  account  for  these  effects,  a second  function  was  added 
to  the  PROASIGN  descriptor.  This  work  was  not  done  under  this  contract, 
but  it  is  reported  here  to  update  the  BALFRAM  documentation. 

The  new  PROASIGN  function  computes  the  sum  of  the  remaining  order  of 
battle  of  a set  of  units  and  compares  it  with  the  product  of  a given  con- 
stant multiplied  by  the  remaining  order  of  battle  of  a specified  unit. 

The  minimum  value  of  the  comparison  is  then  allocated  to  the  set  of  units 
according  to  the  apportionment  factors. 

Appendix  A contains  a description  of  the  new  PROASIGN  function  for 
insertion  into  the  appropriate  place  in  the  BALFRAM  User  Manual. 

2.3.5  Program  Control  Card  Changes 

Several  minor  changes  were  made  on  the  Program  Control  Card  to  permit 
input  of  additional  control  information. 

During  this  contract,  fields  17  to  26  (columns  51  to  70)  were  added 
as  input  flags  to  control  BALFRAM  processing.  Only  fields  17  and  18  cur- 
rently have  significance--the  remaining  fields  are  available  for  future 
use.  Field  17  controls  the  production  of  a file  for  use  with  a plotting 
program.  SRI  wrote  a small,  off-line  plotting  routine  to  test  the  capa- 
bility for  plotting,  but  no  plotting  capability  was  included  in  BALFRAM 
at  this  time.  Field  18  adds  another  control  to  the  printing  of  the  battle 
history.  When  field  18  contains  a 1 battle  history  is  printed  only  if 
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an  event  other  than  a time  update  occurs.  This  feature  limits  the  output 
to  only  significant  events. 

Other  changes  were  made  to  the  Program  Control  Card  prior  to  the 
current  SRI  contract,  but  they  were  not  formally  documented  previously. 
Field  5 was  originally  used  only  to  control  the  number  of  battle  steps 
before  beginning  the  battle  history  printout.  As  an  added  feature,  the 
battle  history  can  be  selectively  printed  every  nth  step  by  entering  -n 
in  field  5.  A +n  works  as  originally  specified.  A new  field  6 (columns 
26-30)  has  been  added  that  controls  the  reading  of  the  NODH  geography. 

To  read  NODH  data  from  file  generated  by  the  NODH  program  a zero  or  blank 
is  entered  in  field  6.  New  fields  7-16  (columns  31-50)  have  been  reserved 
for  a user  supplied  program  logic  indicator  array.  Although  read  and 
printed  this  array  is  not  otherwise  used  apparently  as  a result  of  other 
program  modifications. 

The  current  version  of  the  Program  Control  Card  is  documented  in 
Appendix  A. 

2.4  CHANGES  IN  PROGRAM  CONTROL  AND  USER  INTERFACE 

In  addition  to  the  changes  in  the  functioning  of  certain  descriptors, 
changes  were  made  in  the  subroutines  that  control  the  BALFRAM  program  and 
that  read  and  print  data.  The  program  was  streamlined  and  the  output 
formats  changed  to  make  the  presentation  of  data  easier  for  the  user  to 
interpret. 

2.4.1  Restructure  the  BALFRAM  Software 

The  BALFRAM  program  used  as  a starting  point  for  this  research  con- 
tained 20  subroutines  used  for  computing  allocation  of  forces  in  a dynamic 
situation  (called  the  SABRE  GRAND  model).  Research  subsequent  to  the 
introduction  of  these  subroutines  into  BALFRAM  showed  that  the  theoretical 
basis  of  these  routines  was  not  compatible  with  BALFRAM.  These  routines 
were  never  used  in  BALFRAM  scenarios,  but  had  not  been  removed  from  the 
program.  These  subroutines  and  the  storage  associated  with  them  were 
removed. 
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Overlays  (or  links  in  Honeywell  terminology)  are  a method  of  seg- 
menting a program  so  that  only  portions  that  are  needed  for  immediate 
execution  are  in  memory.  This  permits  large  programs  to  execute  in  a 
smaller  memory  space.  The  original  BALFRAM  overlay  structure  used  overlay 
methods  unique  to  Honeywell  computers.  These  methods  increased  the  effort 
necessary  to  transfer  BALFRAM  to  other  commands  or  other  potential  users. 

A new  overlay  structure  was  designed  and  implemented  that  provided 
a tree-like  hierarchy  of  subroutine  calling  sequences  and  overlay  parti- 
tions. This  sequence  can  be  implemented  on  the  Honeywell  as  well  as  other 
computers  (such  as  the  GDC  6400  at  SRI)  with  only  minor  syntax  changes 
to  reflect  the  host  computer  linkage  syntax. 

Figure  1 shows  the  new  overlay  structure  and  subroutine  calling 
sequence.  The  new  structure  requires  copies  of  some  subroutines  (LLRKl, 
MLRKl,  and  the  geometric  subroutines)  in  two  overlays.  This  is  imple- 
mented easily  by  placing  these  subroutines  in  a user  library  so  that  the 
loader  has  access  to  the  routines  for  loading  both  overlays,  yet  only  one 
copy  of  the  FORTRAN  programs  need  be  maintained. 

2.4.2  Corrections  to  the  Nonhomogeneous  Linear  Battle 

One  of  the  B.'LFRAM  program  difficulties  identified  by  analysts  was 
the  Inability  to  run  nonhomogeneous  linear  battles  with  surveillance. 
Analyst  intuition  and  manual  checking  revealed  that  the  answers  produced 
were  unreasonable.  Further  analysis  and  test  cases  run  by  SRI  eventually 
traced  the  error  to  a typographical  error  in  a variable  name  in  subroutine 
INVLB,  which  subsequently  was  corrected. 

2.4.3  Revision  of  BALFRAM  Outputs 

Several  changes  were  made  to  make  BALFRAM  outputs  easier  to  read  by 
reformatting  the  output  or  correcting  errors  in  producing  the  outputs. 

If  the  full  battle  history  printout  is  selected  for  a BALFRAM  sce- 
nario, the  resultant  output  is  an  extremely  large  amount  of  paper,  only 
part  of  which  is  useful.  The  large  quantity  of  paper  is  caused  by  the 
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•Entry  Point 

^G«om«tric  Routines  include; 

ACOSH  EXM1 

ACOTH  EXM2' 

ACSSCH  EXiWIJ* 

ASEC  HCSCT 

ASINH  SECTAN 

COSH  SINH  SA-5822-1 


FIGURE  1 BALFRAM  SUBROUTINE  LINKAGE  SEQUENCE 
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number  of  events  triggered  by  both  battle  contingencies  and  by  the  passage 
of  simulated  time.  One  of  the  new  option  indicators  that  can  be  set  at 
input  time  will  disable  the  battle  history  print  of  routine  time  update 
events,  which  leaves  only  the  contingency  events  in  the  battle  history. 

This  change  can  reduce  the  amount  of  the  battle  history  print. 

New  output  formats  were  designed  for  the  program  control  card  data 
and  the  BTLENODE -Homogeneous  descriptor  data.  The  amount  of  descriptive 
labeling  was  increased  and  all  the  data  pertaining  to  each  node  was  dis- 
played together  to  facilitate  comparison. 

A correction  was  made  to  the  logic  that  controls  the  printing  of 
FEBA  movement  history,  logistic  interdiction  history,  and  interpreted 
descriptors  for  sensitivity  analysis  iterations.  Previously,  the  print- 
outs were  not  enabled  at  the  proper  times  during  the  battles. 

Formats  for  the  NODH  geography  program  were  changed.  Additional 
labeling  information  was  included  on  the  printout  of  the  three  matrices 
(input  distance,  minimum  distance,  and  next  node  in  shortest  path).  A 
listing  of  the  input  in  a descriptive  format  was  also  added  for  ease  of 
checking  the  input  data. 

All  FORMAT  statements  for  error  messages  in  BALFRAM  and  NODH  were 
rewritten  to  provide  added  identification  information  for  error  resolu- 
tion. The  subroutine  name  and  FORMAT  statement  number  were  added  to  the 
text  of  the  error  message.  This  will  facilitate  error  resolution  by 
identifying  the  location  in  the  program  where  the  error  was  processed. 

To  facilitate  adding  a full  plotting  capability  for  the  time  variation 
of  selected  variables,  one  of  the  BALFRAM  input  files  (file  1)  was  con- 
verted to  a plot  file.  This  file  was  originally  used  only  during  the 
input  processing  and  was  therefore  able  to  be  additionally  used  for  plot- 
ting data  during  the  simulation.  An  option  switch  was  established  in  the 
input  to  enable  writing  the  plot  tape  when  desired.  A small  off-line 
plotting  routine  was  written  for  the  SRI  version  of  BALFRAM  to  test  the 
feasibility  of  plotting  data. 
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version  of  BALFRAM  printed  all  the  input  data  twice--once  with  the  input 
cards  numbered  consecutively  as  they  '-'ere  read  into  the  program  and  a 
second  time  when  each  card  was  edited,  'fhe  second  list  was  Intended  to 
be  used  when  there  were  editing  errors.  This  second  list  was  changed  to 
print  input  only  when  an  error  is  present. 

Each  section  of  the  input  processing  that  reads  a descriptor  with 
the  designation  "Ked"  or  "Blue"  contains  program  statements  to  interpret 
the  color.  Since  26  of  33  descriptors  have  such  information,  there  is 
much  redundant  programming.  In  preparation  for  the  major  design  changes 
of  interactive  BALFR^XM,  a code  was  written  to  interpret  the  side  only 
once  during  the  input  processing.  New  descriptors  added  during  this  con- 
tract and  any  descriptor  input  processing  that  is  changed  will  take  advan- 
tage of  this  coding  to  reduce  the  program  length  for  processing  input. 

To  improve  the  flexibility  of  BALFRAM  for  future  software  changes, 
a new  COMMON  storage  area  has  been  inserted.  This  COMMON  has  a floating 
point  and  a fixed  point  array  that  can  be  used  when  communication  is 
required  between  subroutines  for  debugging  or  testing.  This  COMMON  also 
includes  an  array  for  selecting  various  processing  options.  Currently, 
only  two  of  the  options  are  utilized  although  there  is  space  for  up  to 
20  options. 


2.4.4  Revisions  to  Input  Processing 


Two  changes  were  made  to  the  processing  of  input  data.  The  original 


3.  SOFTWARE  DOCUMENTATION 


3.1  INTRODUCTION 

As  part  of  this  research  on  an  interactive  BALFRAM  program,  SRI  up- 
dated the  software  documentation  of  the  BALFRAM  program.  In  addition, 
to  updating  existing  documentation  to  indicate  the  current  status  of  the 
model  after  the  most  recent  changes,  new  documentation  was  developed. 
Section  3 discusses  this  documentation.  The  purpose  of  this  documenta- 
tion work  is  to  make  the  design  and  implementation  of  interactive  BALFRAM 
faster  and  more  efficient  by  providing  tools  for  Identifying  and  under- 
standing the  pertinent  sections  of  the  BALFRAM  software. 

Some  documentation  is  too  voluminous  to  be  included  in  this  section 
of  the  report  and  is  more  appropriately  placed  in  appendices.  The  appen- 
dix material,  however,  is  discussed  in  this  section.  Information  dis- 
cussed previously  in  the  report  is  also  referenced  in  this  section  to 
provide  in  one  section  a complete  discussion  of  software  documentation. 

3.2  BALFRAM  PROGRAM  STRUCTURE 

In  subsection  2.4.1,  the  restructuring  of  the  BALFRAM  software  was 
discussed.  In  that  section.  Figure  1 showed  the  overlay  structure  and 
subroutine  calling  sequence.  Figure  1 is  also  important  software  docu- 
mentation for  understanding  the  physical  organization  of  the  BALFRAM 
program  and  the  hierarchy  of  references  between  subroutines.  Further 
information  on  the  purpose  of  each  subroutine  can  be  found  in  the  BALFRAM 
Program  Maintenance  Manual,  Section  2. 2. 2.1.  Additional  information  on 
the  logic  and  local  variables  of  each  subroutine  can  be  found  in  the 
BALFRAM  Program  Notebook  developed  during  this  research  and  included  with 
the  BALFRAM  working  notes  in  the  Research  and  Analysis  Office  (J77)  at 
CINCPAC. 
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3.3  BLOCK  DIAGRAMS  OF  HALF RAM  CONTROL  ROUTINES 

To  document  more  fully  the  logical  working  of  the  BALFRAM  program, 
the  major  control  subroutines  were  block  diagrammed  during  this  research. 

The  block  diagrams  show  the  flow  of  program  processing  at  a macro-level 
of  detail.  Individual  FORTRAN  statements  are  not  shown,  but  collections 
of  statements  that  perform  particular  functions  are  shown  along  with  the 
logical  branches  that  control  the  execution  of  the  major  program  sections. 

At  this  level  of  detail,  the  Important  program  construction  and  logical 
features  are  evident  without  the  confusing  burden  of  detailed  variable 
processing.  The  block  diagrams  are  keyed  to  the  FORTRAN  program  by  ref- 
erencing program  statement  numbers  so  that  specific  details  in  the  pro- 
gram can  be  readily  identified.  Table  3 provides  a list  of  those  sub- 
routines for  which  block  diagrams  have  been  drawn.  Because  of  the  volume  | 

of  the  block  diagrams,  they  are  included  in  Appendix  B.  | 

3.4  COMMON  VARIABLE  DEFINITIONS  i 

i 

The  information  content  of  variables  is  critical  to  understanding  j 

and  changing  a program.  A dictionary  of  the  variables  in  each  COMMON  j 

block  of  BALFRAM  has  been  assembled  and  updated  during  this  research. 

Because  of  the  number  of  variables,  the  tables  containing  the  definitions 
are  presented  in  Appendix  C. 

In  the  BALFRAM  program,  variables  are  assembled  into  COMMON  blocks 
according  to  their  usage.  Generally  variables  associated  with  a partic-  ! 

ular  descriptor  are  organized  into  the  same  COMMON  block.  To  preserve  i 

the  correspondence  of  variables  and  their  CCMMON  blocks,  the  variable  | 

definitions  are  also  organized  by  COMMON  block.  All  variables  in  each 
CCMMON  block  are  defined,  their  size  (DIMENSION)  given,  and  the  source  i 

of  the  data  is  provided  for  cross  reference. 

i 

3.5  SUBROUTINE  COMMON  REFERENCES  ! 

I 

J 

When  interpreting  and  debugging  programs  it  is  important  to  know  I 

the  information  contained  by  each  variable  and  the  subroutines  where  the  | 

variable  values  are  defined  and  referenced.  The  information  definition 
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Table  3 


SUBROUTINE  BLOCK  DIAGRAM  LIST 


Subroutine 

Block-Diagrammed 

Subroutine  Purpose 

INILT 

Reads  and  edits  input  descriptors  for  errors. 

SURFGN 

The  main  driver  for  battle  computations. 

Establishes  initial  conditions  for  battle  via 
FRCRATIO,  DSTRIBUT,  and  RANDMSEQ  control  instruc- 
tions . 

RANDM 

Randomizes  designated  input  parameters  according 
to  RANDMSEQ  card  set  inputs  and  assigns  variable 
values  for  individual  battles. 

TSMO 

The  main  battle  scenario  driver.  Controls 
scenario  by  determining  next  event  and  time. 

Writes  battle  history. 

BATTLE 

Calculates  attrition  during  the  interaction  of 
homogeneous  forces. 

INVBAT 

Computes  the  time  required  for  units  engaged  in 
homogeneous  battle  to  reach  their  respective 
defeat  criteria. 

LINBAT 

Calculates  attrition  during  linear,  nonhomogeneous 
interactions . 

INVLB 

Computes  the  time  required  for  units  engaged  in 
linear  nonhomogeneous  battle  to  reach  their 
respective  defeat  criteria. 

ADCP5 

Processes  parameter  changes  as  required  by  the 
PARMCHNG  descriptors. 
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was  discussed  in  Section  3.4.  The  subroutine  usage  of  variable  data  is 
discussed  in  this  section. 

Compiler  variable  maps  give  only  definition  and  reference  information 
relative  to  a single  subroutine  (intra-subroutine).  For  tracing,  variable 
references  are  needed  on  a global  basis  (inter-subroutine).  Special  pro- 
grams must  be  executed  to  obtain  such  information.  In  the  absence  of 
complete  global  information,  knowledge  of  the  COMMON  references  by  sub- 
routine are  useful  in  tracing  the  usage  of  a particular  variable.  Table  4 
provides  the  map  of  COMMON  block  references  by  subroutine  for  BALFRAM. 

In  Table  4,  individual  subroutines  can  be  identified  as  users  of  a COMMON 
containing  a variable  of  interest.  Reference  to  the  compiler  variable 
map  can  then  be  used  to  identify  the  usage  of  the  particular  variable. 

3.6  BALFRAM  FILE  DESCRIPTIONS 

The  BALFRAM  program  uses  disk  files  to  read  input,  to  write  output 
for  the  printer,  and  to  store  intermediate  results  for  minimizing  the 
requirements  for  memory.  Table  5 describes  the  files  used  by  BALFRAM. 

The  File  Logical  Unit  Number  is  the  unit  number  referenced  by  the  READ 
or  WRITE  statements  in  the  program.  On  the  WWMCCS  computer,  this  number 
is  linked  to  a physical  file  through  a FILE  or  PRMFL  control  card  in  the 
job  control  deck  depending  on  the  disposition  of  the  file.  On  the  SRI 
CDC  6400  computer,  the  file  logical  unit  number  is  linked  to  a physical 
file  through  the  file  designations  on  the  FORTRAN  PROGRAM  card  and  through 
the  job  control  cards. 

Table  5 indicates  the  subroutines  where  files  are  used  and  the  in- 
formation content  of  the  files.  Files  1 and  2 are  created  by  copying  the 
input  file  and  are  used  to  read  each  input  card  twice.  The  first  read 
(from  file  2)  is  used  to  determine  the  type  of  descriptor  of  the  input 
card.  After  branching  to  the  appropriate  section  in  subroutine  INPUT,  the 
descriptor  card  is  read  from  file  1 according  to  the  proper  FORMAT  for 
that  descriptor. 

Files  50,  52,  and  54  store  variable  initializations  when  sensitivity 
studies  are  to  be  generated.  FRCRATIO,  DSTRIBUT,  and  RANDMSEQ  descriptors 
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(Continued) 


OVL23 

OVL245 


Table  4 (Continued) 


OVL245 


'I 


scale  variables  with  multiplicative  constants.  For  each  variation,  the 
program  variables  must  be  restored  to  the  appropriate  initial  values  by 
reading  one  of  the  files.  File  42  stores  the  summary  values  for  each 
variation  in  the  sensitivity  studies  to  minimize  the  memory  required. 
After  the  last  sensitivity  variation,  file  42  is  read,  and  the  summary 
output  formatted  and  printed  by  subroutine  OUTMTR. 

3.7  DESCRIPTOR  PROCESSING 

In  designing  and  implementing  interactive  the  BALFRAM  program,  de- 
scriptor processing  will  be  altered.  To  make  changes,  it  is  important 
to  know  where  the  processing  for  each  descriptor  takes  place.  Users  of 
the  existing  BALFRAM  also  need  such  a cross  reference  to  make  their  own 
changes  to  descriptor  processing.  Table  6 provides  a reference  to  the 
subroutine  where  each  descriptor  is  processed,  both  during  input  editing 
and  during  the  execution  of  the  contingency  logic.  Since  all  input  and 
editing  is  done  in  three  very  large  subroutines,  statement  numbers  are 
furnished  to  further  locate  the  input  processing  sections. 
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Table  6 


BALFRAM  DESCRIPTORS  PROCESSING  CROSS  REFERENCE 


Descriptor 

Acronym 

Location  of  Input 
Processing 

Location 
of  Logical 
Processing 

Descriptor  Purpose 

Subroutine 

Name 

Statement 

Number 

Subroutine 

Name 

Program  Control  Instructions 


Title  Card 

INILT 

12 

None 

Descriptive  title  information 

Program 

Control 

Card 

INILT 

20 

INILT 

Sets  general  program  parameters 

LINSOLU 

INPUTS 

2000 

LINSOL 

Generates  the  order  of  battle  required  to 
produce  a stipulated  outcome 

SIWIARY 

INPUT 

1000 

OUTMTR 

Summarizes  survivors,  firepower  results, 
duration  of  battle 

SUMTITLE 

INPUT 

1900 

OUTMTR 

Provides  headings  for  summaries 

END 

INPUT 

9998 

INPUT 

Signals  completion  of  input 

Force  Definition  Inputs 


UNITSPEC 

INPUT 

None 

Describes  combat  forces 

GL’ERILU 

INPUT 

INPUT 

Establishes  disengagement  rules 

PAR.MCHNC* 

INPUTB 

ADCP5 

Changes  parameters,  such  as  order  of  battle. 

1 1 

firepower 

Battle  Logic  Inputs 


BTLENODE 

INPUT 

1100 

ADCP 

Describes  nodes  for  homogeneous  and  non- 
homogeneous  battles 

STOPBTLE 

INPUTC 

700 

ADCP 

Terminates  the  battle 

NODATFAC 

INPUT 

1300 

ADCP  3 

Sets  attrition  factors  for  specified 
conditions 

NODEPROP 

INPUT 

500 

ADCP 

Specifies  allocation  and  effectiveness  of 
supporting  firepower 

SL'MUNIT 

INPUTB 

3100 

ADCP  7 

Permits  orders  of  battle  of  several  units 
to  be  merged 

EXOCUNIT 

INPUTB 

2300 

ADCP 

Directs  firepower  to  enemy  units  at  nodes 
occupied  by  friendly  units 

OPEXOGUN 

INPUTB 

21*00 

ADCP 

Directs  supporting  firepower  at  the  loca- 
tions of  specified  units 

PROAS IGN 

INPUT 

1400 

ADCP2 

Proportionally  assigns  and  redistributes 
forces 

LGINTDIC  1 

INPUTB 

2600 

ADCP4 

Describes  logistic  pipelines  and  effects  of 
interdiction 

Movement  Logic  Inputs 


ADVANCE 

INPUT 

400 

ADCP  2 

Moves  units  from  node  to  node  contingent  on 
arrival  events 

RETREAT 

INPUT 

600 

ADCP  2 

Moves  units  contingent  on  defeat  events  at 
nodes 

OBJCTADV 

INPUT 

1200 

ADCP  3 

Relocates  units  when  enemy  is  defeated 

STRTEGRT 

INPUT 

1700 

ADCP  3 

Withdraws  units  if  force  ratio  is 
unf  avorable 

TIMEADVN 

INPUT 

2200 

ADCP 

Relocates  units  at  specified  times 

CHASE 

INPUTC 

1500 

ADCP  2 

Causes  one  force  to  track  another 

RENDEVOU 

INPUTC 

1600 

ADCP  2 

Establishes  a sequential  link-up  of  forces 

REDEPLOY 

INPUTC 

300 

ADCP 

Redeploys  units  after  battle  is  won 

FEBAMOVE 

INPUTB 

1 

2900 

ADCP6 

Traces  movement  of  forward  edge  of  the 
battle  area 

Sensitivity  Analysis  Instructions 


FRCRATIO 

INPUT 

200 

SURFGN 

Multiplies  order  of  battle,  ICE,  or  fire- 

power  to  vary  scenario  outcome 

DSTRIBUT 

INPUT 

900 

SURFGN 

Allocates  forces  between  two  missions  and/ 

or  areas 

RANDMSEg 

INPUTB 

2500 

RANDM 

Generates  parameter  sensitivity  studies 

*Also:  PVCHANGE,  UVCHANGE,  UNCHANGE. 
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Appendix  A 

REVISED  USER  MANUAL  DESCRIPTOR  DOCUMENTATION 

I.  INTRODUCTION 

During  the  interactive  BALFRAM  research,  new  functions  were  added 
to  several  of  the  descriptor  cards.  Because  these  modifications  affected 
the  input  of  data,  the  descriptions  of  input  data  assembly  in  the  User 
Manual*  were  outdated.  The  following  sections  of  this  appendix  update 
the  descriptor  documentation  to  include  new  functions  and  capabilities. 
This  new  documentation  should  replace  existing  documentation  in  the  User 
Manual.  New  documentation  is  included  for: 

• Program  control  card 

• Parameter  change  cards 

• STOPBTLE  card 

• PROAS IGN  card 

• UNITSPEC,  LGINTDIC,  and  SUMUNIT  cards. 


•k 

E.  H.  Means,  C.  L.  Phillips,  and  S.  E.  Young,  BALFRAM  User  Manual  for 
the  Staff  of  the  Commander  in  Chief  Pacific,"  Stanford  Research  Institute, 
Menlo  Park,  CA  94025,  Technical  Note  NWRC-TN-52,  September  1974. 
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PROGRAM  CONTROL  CARD  (615,2012) 


A Program  Control  Card  must  immediately  follow  the  Title  Card  for 
each  BALFRAM  scenario.  The  Program  Control  Card  provides  options  for 
user  control  of  the  scenario  processing: 

(1)  FIELD  1 (columns  1-5)  (15)  states  how  many  nodes  (i.e.,  the 
highest  node  number)  are  in  the  NODH  file  (file  20)  for  scenario 
geography.  This  number  must  not  exceed  80. 

(2)  FIELD  2 (columns  6-10)  (15)  contains  the  code,  listed  below,  for 
the  default  fight  law,  which  is  implemented  when  a fight  law  is 
not  specified  on  the  applicable  BTLENODE  card.  (See  Appendix  B 
of  the  User  Manual  for  discussion  of  fight  laws.) 


Code 


Law 


Blank  or  1 
2 
3 


4 


Differential  square  fight  law. 

Differential  linear  fight  law. 

Differential  mixed  fight  law: 
BLUE  suffers  attrition  by  the 
differential  square  fight  law, 
RED  suffers  attrition  by  the 
differential  linear  fight  law. 

Differential  mixed  fight  law: 
RED  suffers  attrition  by  the 
differential  square  fight  law, 
BLUE  suffers  attrition  by  the 
differential  linear  fight  law. 


(3)  FIELD  3 (columns  11-15)  (15)  sets  the  maximum  number  of  battle 
steps  to  be  performed.  This  limits  the  effects  of  possible 
loops  in  the  calculations.  It  also  enables  the  analyst  to 
limit  the  scenario  play  for  test  purposes. 


(4)  FIELD  4 (columns  16-20)  (15)  contains  a code,  listed  below, 
that  governs  the  printout  of  scenario  results. 


Code 


Printout 


0 Complete  battle  history,  FEBA 

movement  history,  logistic  in- 
terdiction history,  and  summa- 
ries. 


1 


Summaries  only. 


Code 


Printout 


2 FEBA  movement  history,  logistic 
interdiction  history,  battle 
node  information,  and  summaries. 

3 Summaries  and  interpreted  de- 
scriptors for  each  sensitivity 
analysis  iteration. 

4 Summaries  plus  normalized  attri- 
tion factors  for  linear  nonhomo- 
geneous  battle. 

(5)  FIELD  5 (columns  21-25)  (15)  sets  the  number  of  battle  steps  to 
be  performed  before  the  battle  history  printout  begins.  If 
this  field  contains  a zero  or  blank,  the  printout  will  begin 
immediately.  If  this  field  is  negative  (i.e.,  -n) , the  battle 
history  is  printed  only  every  nth  step. 

(6)  FIELD  6 (columns  26-30)  (15)  contains  blank  or  zero  if  the 
geography  of  the  scenario--distance  between  nodes,  minimum 
distance  between  any  two  nodes,  and  the  matrix  of  next  nodes 
in  the  path  of  minimum  distance--is  to  be  read  in  from  file  20. 
Any  other  values  are  ignored. 

(7)  FIELDS  7 to  16  (columns  31-50)  (1012)  consist  of  a user  supplied 
program  logic  indicator  array  that  is  presently  unused. 

(8)  FIELDS  17  to  26  (columns  51-70)  (1012)  are  indicators  for  se- 
lecting processing  options.  A blank  or  0 in  an  option  field 
has  no  effect;  a 1 has  the  following  effect; 


Field 

Columns 

Processing  Option 

17 

51-52 

Write  variables  on  file  1 after  each  event  step 
for  subsequent  plotting  or  c her  processing. 

18 

53-54 

Print  battle  history  for  an  event  only  if  it  is 
not  the  result  of  a game  time  increment  (i.e,, 
print  only  nonroutine  events) . 

19  to  26 

55-70 

Not  presently  used. 
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3.  PARAMETER  CHANGE  CARDS 

The  single  PARMCHNG  Card  in  the  original  BALFRAM  has  been  augmented 
by  three  new  cards  for  changing  parameter  values  at  specified  times  during 
a BALFRAM  scenario.  The  individual  cards  differ  in  the  combinations  of 
parameter  codes,  new  values,  and  units  on  each  card  type.  A maximum  of 
100  parameter  changes  is  permitted  in  a scenario.  Each  of  the  multiple 
changes  on  a single  PVCHANGE,  UVCHANGE,  and  UNCHANGE  card  is  counted  as 
one  parameter  change.  In  contrast  to  the  original  BALFRAM,  all  parameter 
change  reset  values  are  subject  to  adjustment  by  FRCRATIO  and  RANDMSEQ 
descriptors,  if  appropriate.  When  changing  NODEPROP  parameters,  see  the 
instructions  associated  with  the  appropriate  field  for  special  conditions: 

(1)  PARMCHNG  Card  (2A4,  2X,  A4,  IX,  215,  2F10.5).  The  PARMCHNG 

(parameter  change)  card  resets  a single  parameter  for  a single 
unit  to  a new  value  at  a given  time  during  the  BALFRAM  scenario; 

(a)  FIELD  1 (columns  1-8)  (2A4)  contains  'PARMCHNG'. 

(b)  FIELD  2 (columns  11-14)  (A4)  contains  'BLUE'  or  'RED'  to 
denote  the  side  to  which  the  parameter  change  applies. 

(c)  FIELD  3 (columns  16-20)  (15)  contains  a code,  listed  below, 
that  indicates  which  parameter  is  to  be  changed: 


Code 


Parameter 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 


Increment  to  unit  order  of  battle  (Field  5,  UNITSPEC 
card).  Note  that  the  increment  must  be  multiplied 
by  the  sortie  rate  before  entry  (if  applicable). 

Not  used. 

ICE  (Field  8,  UNITSPEC  card). 

Mobility  factor  (Field  10,  UNITSPEC  card). 

Nodal  objective  of  unit  (Field  12,  UNITSPEC  card). 
Not  used. 

Exogenous  firepower  target  node  (Field  13, 

UNITSPEC  card). 

Disengagement  code  (Fields  5,7,9 GUERILLA 

card) . 

Defeat  criterion--actual  order  of  battle,  not 
percent  (see  Field  7,  UNITSPEC  card). 

Nodal  location  of  units  used  to  compute  exogenous 
firepower  (Field  4,  NODEPROP  card). 

Target  node  for  exogenous  firepower  (Field  5, 
NODEPROP  card). 
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Code 


Parameter 


T 


I 


1 


12 

13 


Node  or  unit  for  additional  code  depending  on 
value  in  Field  7 of  NODEPROP  card  (Field  6, 
NODE PROP  card). 

Exogenous  firepower  computation  code  (Field  7, 
NODEPROP  card). 


(d)  FIELD  4 (columns  21-25)  (15).  If  Field  3 is  9 or  less, 
Field  4 contains  the  identifier  of  the  unit  that  is  to 
have  a parameter  changed.  If  Field  3 is  10  or  more,  Field 
4 contains  the  sequential  position  of  the  NODEPROP  card 

to  be  changed  with  respect  to  all  NODEPROP  cards  in  the 
input. 

(e)  FIELD  5 (columns  26-35)  (F10.5)  contains  the  time  at  which 
the  parameter  is  to  change. 

(f)  FIELD  6 (columns  36-45)  (F10.5)  contains  the  new  value  of 
the  parameter. 


(2)  PVCHANGE  card  (2A4,  2X,  A4,  IX,  F10.5,  15,  4 (13,  F7.2)).  The 
PVCHANGE  (parameter  and  value  change)  card  resets  multiple 
parameters  for  a single  unit  or  NODEPROP  card  at  a given  time 
in  the  BALFRAM  scenario: 


(a)  FIELD  1 (columns  1-8)  (2A4)  contains  'PVCHANGE'. 

(b)  FIELD  2 (columns  11-14)  (A4)  contains  'BLUE'  or  'RED'  to 
denote  the  side  to  which  the  parameter  change  applies. 

(c)  FIELD  3 (columns  16-25)  (F10.5)  contains  the  time  at  which 
the  parameters  are  to  change. 

(d)  FIELD  4 (columns  26-30)  (15).  If  Field  5 is  9 or  less, 
Field  4 contains  the  identifier  of  the  unit  that  is  to 
have  a parameter  changed.  If  Field  5 is  10  or  more. 

Field  4 contains  the  sequential  position  of  the  NODEPROP 
card  to  be  changed  with  respect  to  all  NODEPROP  cards  in 
the  input. 

(e)  FIELDS  5,7,9,  and  11  (columns  31-33,  41-43,  51-53,  61-63) 
(13)  contain  a code  that  indicates  which  parameter  is  to 
be  changed.  The  codes  are  same  as  for  Field  3 of  the 
PARMCHNG  card,  described  in  3(1),  above.  All  codes  on  a 
single  PVCHANGE  card  must  be  either  9 or  less  or  10  or 
greater  to  preserve  the  correspondence  with  Field  4. 

(f)  FIELDS  6,8,10,  and  12  (columns  34-40,  44-50,  54-60,  64-70) 
(F7.2)  contain  the  new  values  of  the  parameter.  See 
UNITSPEC  and  NODEPROP  descriptor  discussions  in  the  User 
Manual  for  applicable  special  conditions  for  these  values. 
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(3)  UVCHANGE  card  (2A4,  2X,  A4,  IX,  F10.5,  15,  4 (13,  F7.2)).  The 
UVCHANGE  (unit  and  value  change)  card  resets  a single  parameter 
on  multiple  UNITSPEC  or  NODEPROP  cards  with  new  values  at  a 
given  time  in  the  BALFRAM  scenario; 

(a)  FIELD  1 (columns  1-8)  (2A4)  contains  'UVCHANGE.' 

(b)  FIELD  2 (columns  11-14)  (A4)  contains  'BLUE'  or  'RED'  to 
denote  the  side  to  which  the  parameter  change  applies. 

(c)  FIELD  3 (columns  16-25)  (F10.5)  contains  the  time  at  which 
the  parameters  are  to  change. 

(d)  FIELD  4 (columns  26-30)  (15)  contains  a code  that  indicates 
which  parameter  is  to  be  changed.  The  codes  are  the  same 
as  for  the  PARMCHNG  card,  listed  in  3(1),  above. 

(e)  FIELDS  5,7,9,  and  11  (columns  31-33,  41-43,  51-53,  61-63) 
(13).  If  Field  4 is  9 or  less.  Field  5,7,9,  and  11  contain 
the  identifier  of  a unit  that  is  to  have  a parameter  changed. 
If  Field  4 is  10  or  more.  Field  5,7,9,  and  11  contain  the 
sequential  position  of  the  NODEPROP  card  to  be  changed  with 
respect  to  all  NODEPROP  cards  in  the  input. 

(f)  FIELDS  6,8,10,  and  12  (columns  34-40,  44-50,  54-60,  64-70) 
(F7.2)  contain  the  new  values  of  the  parameter.  See 
UNITSPEC  and  NODEPROP  descriptor  discussions  in  the  User 
Manual  for  applicable  special  conditions  for  these  values. 

(4)  UNCHANCil  card  (2A4,  2X,  A4,  IX,  F10.5,  15,  3X,  F7.2,  1013).  The 
UNCHANGE  (unit  change)  card  resets  a single  parameter  on  mul- 
tiple UNITSPEC  or  NODEPROP  cards  to  a single  value  at  a given 
time  in  the  BALFRAM  scenario: 


(a)  FIELD  1 (columns  1-8)  (2A4)  contains  'UNCHANGE.' 

(b)  FIELD  2 (columns  11-14)  (A4)  contains  'BLUE'  or  'RED'  to 
denote  the  side  to  which  the  parameter  change  applies. 

(c)  FIELD  3 (columns  16-25)  (F10.5)  contains  the  time  at  which 
the  parameters  are  to  change. 

(d)  FIELD  4 (columns  26-30)  (15)  contains  a code  that  indicates 
which  parameter  is  to  be  changed.  The  codes  are  the  same 
as  for  Field  3 of  the  PARMCHNG  card,  described  in  3(1), 
above. 


(e)  FIELD  5 (columns  34-40)  (F7.2)  contains  the  new  values  of 
the  parameter  to  be  used  for  all  units  or  NODEPROP  cards. 
See  the  UNITSPEC  and  NODEPROP  descriptor  discussions  in 
the  User  Manual  for  the  applicable  special  conditions  for 
this  value. 


(f)  FIELDS  6ff.  (columns  41-43,  44-46,  ...,  68-70).  If  Field 
4 is  9 or  less.  Fields  6ff.  contain  the  identifier  of  the 
unit  that  is  to  have  the  parameter  changed.  If  Field  4 
is  10  or  more,  these  fields  contain  the  sequential  posi- 
tion of  the  NODEPROP  card  to  be  changed  with  respect  to 
all  NODEPROP  cards  in  the  input. 


J 
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4. 


STOPBTLE  CARD  (2A4,  2X,  A4,  IX,  15,  2013/1013) 


STOPBTLE  (stop  battle)  cards  cause  the  scenario  play  to  terminate 
when:  all  the  units  designated  on  a STOPBTLE  card  fall  below  their 

respective  defeat  criteria  (Field  7,  UNITSPEC  card);  any  one  of  the  units 
designated  on  the  STOPBTLE  card  attains  its  geographic  objective  (Field 
12,  UNITSPEC  card) ; or  simulated  game  time  exceeds  the  designated  time. 

A maximum  of  5 STOPBTLE  cards  is  permitted: 

(1)  FIELD  1 (columns  1-8)  (2A4)  contains  'STOPBTLE.' 

(2)  FIELD  2 (columns  11-14)  (A4)  contains  'BLUE'  or  'RED'  to  denote 
the  side  on  which  the  designated  units  fight.  Use  either  BLUE 
or  RED  for  time  limit. 

(3)  FIELD  3 (columns  16-20)  (15)  indicates  how  many  values  are 
entered  in  Fields  4ff.  (must  be  30  or  less). 

(a)  For  defeat  criteria,  enter  the  number  of  units  governed 
by  this  card. 

(b)  For  attaining  objective,  enter  the  number  of  units  governed 
by  this  card  plus  1. 

(c)  For  time  limit,  enter  2. 

(4)  FIELD  4 (columns  21-23)  (13)  contains  a unit  identifier  or  a 
code  indicating  alternate  use  of  the  STOPBTLE  card. 

(a)  For  defeat  criteri.  , enter  the  unit  identifier  of  the 
first  unit  governed  by  this  card. 

(b)  For  attaining  objective,  enter  -2  (negative  2). 

(c)  For  time  limit,  enter  -1  (negative  1). 

(5)  FIELD  5 (columns  24-26)  (13)  contains  a unit  identifier  or  the 
time  limit  for  stopping  the  battle. 

(a)  For  defeat  criteria,  enter  the  unit  identifier  of  the 
second  unit  governed  by  this  card  (if  any). 

(b)  For  attaining  objective,  enter  the  unit  identifier  of  the 
first  unit  governed  by  this  card. 

(c)  For  time  limit,  enter  the  time  limit  for  ending  the  game 
rounded  to  the  nearest  integer  and  entered  without  a 
decimal  point. 

(6)  FIELDS  6ff.  (columns  27-29,  30-32,  ...,  78-80,  1-3,  ...)  (13) 
contains  the  unit  identifiers  for  the  remaining  units  in  the 
list  for  defeat  criteria  or  attaining  objective.  A continua- 
tion card  may  be  used  if  required,  format  (13),  beginning  in 
column  1.  If  the  entry  in  Field  3 is  20,  a blank  continuation 
card  is  required  even  though  all  the  units  are  listed  on  the 
basic  card. 
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5.  PROASIGN  CARD  SET 

The  PROASIGN  (proportional  assignment)  card  sets  apportion  the  forces 
in  a theater  of  war.  At  each  step  in  the  model  calculations,  the  total 
surviving  order  of  battle  of  a set  of  units  is  redistributed  among  the 
units  according  to  specified  rules.  Two  sets  of  rules  are  available  with 
the  PROASIGN  card.  One  set  is  described  in  the  BALFRAM  User  Manual.  This 
section  documents  an  additional  set  added  subsequent  to  publication  of  the 
User  Manual.  A maximum  of  twenty  total  PROASIGN  cards  is  permitted. 

With  this  alternate  use  of  the  PROASIGN  Card,  two  sets  of  units  are 
used--Set  A and  Set  B.  Set  A is  used  in  a fashion  similar  to  the  set  of 
units  in  the  other  use  of  the  PROASIGN  card.  The  BALFRAM  program  com- 
putes two  control  values--the  sum  of  the  remaining  order  of  battle  of  the 
units  in  Set  A and  the  product  of  a constant  (last  value  entered  in 
Fields  12  to  18)  multiplied  by  the  remaining  order  of  battle  of  the  unit 
in  Set  B.  The  program  then  apportions  the  lesser  of  these  two  values  to 
the  units  in  Set  A according  to  the  factors  specified  (in  Fields  12  to  18) : 

(1)  Card  1 for  PROASIGN  Set  (2A4,  2X,  A4,  212,  713,  IX,  7F5.1); 

(a)  FIELD  1 (columns  1-8)  (2A4)  contains  'PROASIGN.' 

(b)  FIELD  2 (columns  11-14)  (A4)  contains  'BLUE'  or  'RED'  to 
denote  the  side  whose  forces  are  to  be  redistributed. 

(c)  FIELD  3 (columns  15-16)  (12)  contains  a 2 to  have  the 
program  read  Card  2 of  this  PROASIGN  card  set. 

(d)  FIELD  4 (columns  17-18)  (12)  Indicates  how  many  units  are 
in  the  two  sets.  This  number  must  be  greater  than  1,  but 
must  not  exceed  7.  Set  B must  contain  exactly  one  unit. 

(e)  FIELDS  5 to  11  (columns  19-21,  22-24,  ...,  37-39)  (13) 
contain  the  identifiers  of  the  units  among  which  the  order 
of  battle  is  to  be  apportioned  (Set  A)  and  the  control 
unit  (Set  B),  given  in  successive  fields  of  three  columns 
each.  Units  to  which  explicit  quantities  of  the  order  of 
battle  are  to  be  assigned  should  be  input  according  to 
priority  and  should  precede  units  that  are  to  receive 
proportional  assignments.  If  the  specified  order  of  battle 
is  insufficient  for  all  of  the  explicit  quantity  assign- 
ments, full  assignments  will  be  made  in  the  order  in  which 
these  units  are  input  until  the  surviving  order  of  battle 
is  exhausted.  Units  must  be  entered  for  Set  A first  fol- 
lowed by  the  Set  B unit. 

(f)  FIELDS  12  to  18  (columns  41-45,  46-50,  ...,  71-75)  (F5.1) 
contain  the  apportionment  factors  applied  to  the  units  in 
Fields  5 to  11  (Set  A)  and  the  constant  multiplier  for  the 
unit  in  Set  B,  respectively.  If  the  numbers  for  Set  A 
are  negative,  the  absolute  value  is  the  explicit  quantity 
of  the  order  of  battle  assigned  to  the  corresponding  unit 
in  Fields  5 to  11.  If  the  numbers  in  these  fields  are 
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positive,  they  indicate  the  fraction  of  the  total  force 
remaining,  after  the  previous  assignments,  to  be  allocated 
to  the  corresponding  unit.  (For  example,  entries  of  0.75, 
0.5,  and  1.0  mean  that  75%  of  the  total  order  of  battle  is 
to  be  assigned  to  the  first  unit,  50%  of  the  remaining 
order  of  battle  to  the  second  unit,  and  all  the  remaining 
order  of  battle  to  the  third  unit.) 

(2)  Card  2 for  PROASIGN  Set  (40X,  F5.1) 

(a)  FIELD  1 (columns  41-45)  (F5.1)  contains  the  negative  num- 
ber of  units  in  Set  A.  The  negative  sign  is  the  indicator 
for  this  alternate  use  of  the  PROASIGN  Card  Set. 
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6.  UNITSPEC,  LGINTDIC,  and  SUMUNIT  Card  Changes 

6.1  UNITSPEC  Card  Change 

The  UNITSPEC  card  describes  the  forces  in  the  BALFRAM  scenario.  A 
single  field  on  the  UNITSPEC  card  has  been  changed  to  require  input  of  an 
initial  sortie  rate  for  the  order  of  battle  resources.  The  following 
paragraph  should  be  inserted  in  the  User  Manual  to  describe  this  change. 

(6)  FIELD  6 (columns  31-35)  (F5.1)  indicates  the  initial  sortie 
rate  for  the  forces  provided  in  Field  5 above.  The  sortie 
rate  is  the  number  of  engagements  performed  per  scenario  time 
unit  for  each  force  element.  The  initial  order  of  battle  used 
in  the  scenario  is  the  product  of  Field  5 and  Field  6.  If  a 
sortie  rate  does  not  apply  to  the  forces  in  Field  5,  1.0  is 
entered  in  Field  6. 

6.2  LGINTDIC  Card  Change 

Field  3 on  the  LGINTDIC  (logistic  interdiction)  card  specifies  the 
number  of  nodes  for  resupply.  The  maximum  number  of  nodes  has  been 
increased  from  10  to  20. 

6.3  SUMUNIT  Card  Change 

Field  5 on  the  SUMUNIT  (summed  units)  card  specifies  the  number  of 
units  that  are  to  have  their  parameters  aggregated.  The  maximum  number 
of  units  has  been  increased  from  10  to  20. 
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BLOCK  DIAGRAMS  OF  BALFRAM  CONTROL  ROUTINES 


Appendix  B 

BLOCK  DIAGRAMS  OF  BALFRAM  CONTROL  ROUTINES 


To  document  more  fully  the  logical  working  of  the  BALFRAM  program, 
this  appendix  presents  block  diagrams  of  the  major  control  routines. 

These  block  diagrams  show  the  flow  of  program  processing  at  a macro-level 
of  detail.  Individual  FORTRAN  statements  that  perform  particular  func- 
tions are  grouped  together  and  described  by  the  function  performed.  The 
logical  branches  that  control  the  execution  of  the  major  program  sections 
are  also  shown.  At  this  level  of  detail  the  important  program  construc- 
tion and  logical  features  are  evident  without  the  confusing  burden  of 
detailed  variable  processing. 

Table  B-1  defines  all  the  symbol  shapes  used  in  the  block  diagrams. 
The  block  diagrams  are  keyed  to  the  FORTRAN  program  by  referencing  pro- 
gram statement  numbers  so  that  specific  code  in  the  program  can  be  readily 
identified.  The  statement  numbers  are  located  on  the  top  left  of  the 
symbol  describing  the  associated  logic.  Capitalized  names  appearing 
within  symbols  are  program  variable  names  and  are  used  to  aid  in  under- 
standing the  detailed  processing  of  the  subprograms.  In  many  cases,  the 
same  processing  is  performed  on  the  Blue  then  the  Red  variables.  In  such 
cases,  the  variable  names  are  separated  by  a slash  (/). 

Block  diagrams  (presented  as  Figures  B-1  to  B-9)  are  Included  in 
this  appendix  for  the  following  subprograms: 


INILT 

• 

INVBAT 

SURFGN 

• 

LINBAT 

RANDM 

• 

INVLB 

TSMO 

• 

ADCP5 

BATTLE 

i 

j 

i 

1 

1 
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Table  B-1 


Definition 


Process  symbol — executing  a defined 
operation  or  group  of  operations 
resulting  in  a change  of  value,  form, 
or  location. 


Process  performed  by  a subroutine  or 
function  named  NAME. 


Input  or  output  function. 


Annotation  function — addition  of  descrip- 
tive comments  or  explanatory  notes. 


Decision  function — switching  operation 
that  determines  which  alternative  path 
is  to  be  followed. 


Terminal  symbol — start  or  end  of  a 
subprogram. 


Connector  symbol — a junction  in  the  line 
of  flow.  Two  connectors  are  used  to 
represent  continued  flow  when  flow  would 
be  broken  by  flow  chart  limitation. 


■ic 

Numbers  on  upper  left  side  of  symbol  (if  present)  Indicate  the  FORTRAN  state- 
ment number  near  or  at  the  point  in  the  program  where  the  described  action  is 
performed. 

Capitalized  names  appearing  within  symbols  refer  to  variables  within  the 
program. 


F 


These  subroutines  are  called  from 
program  INILTl  in  OVERLAY  1,1 


These  subroutines  are  called  from 
program  INILT2  in  OVERLAY  1.2 


SA-5822-2 


FIGURE  B-1  SUBROUTINE  INILT  BLOCK  DIAGRAM 
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Subroutine 

SURFGN 


Initialize  FRCRATIO  and  DSTRIBUT  loop 
variables 

Compute  index  limits  for  SUMMARY  outputs 


FRCRATIO  and 
DSTRIBUT  Loop 


Write  COMMON  data  on 
file  50  to 

save  initial  conditions 


Set  initial  force  level  multiple  and 
counter(M)  for  appropriate  FRCRATIO 
cards  and  DSTRIBUT  cards 
(Nested  loops  with  separate  entry  points! 


Read  COMMON  data 

from  file  50  to  reset  initial  conditions 


Loop  over  all  FRCRATIO  cards  varying 
appropriate  parameters 


Loop  over  all  DSTRIBUT  cards 
apportioning  order  of  battle  between 
appropriate  units 


Zero  RANDMSEQ  cards^ 


Write  COMMON  data 
on  file  54  to  save  initial  conditions 
after  processing  a FRCRATIO  and 
DSTRIBUT  variation 


SA-5822-3 


FIGURE  B-2  SUBROUTINE  SURFGN  BLOCK  DIAGRAM 
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This  subroutine  is  called 
from  program  SURFG2 
in  OVERLAY  2,  2 


Store  values  for  summary  parameters 
in  summary  matrix  and  on  file  42 
Print  summary  matrix  if  last  FRCRATIO 
and  OSTRIBUT  variation 


Increment  loop  counter  (NRSX)  and  check 
if  RANDMSEQ  variations  are  sufficient  / 


'For  OSTRIBUT  & FRCRATIO  variations^ 
Increment  counter  (M(i)] 

Increment  parameter  value 
V Test  if  loop  satisfied  / 


Loops  not  satisfied 


AM  loops  satisfied 


SA-5822-3a 


FIGURE  B-2  SUBROUTINE  SURFGN  BLOCK  DIAGRAM  (Concluded) 


Subroutine 

RANOM 


Loop  on  PARMCHNG 
^ard* 


Set:  Parameter  change  code  (NC) 

Number  of  units  (JJ) 

Ratio  for  scaling  parameters  (RSFAC) 


Does  parameter  code 
equal  6? 


Scale  order 

of  battle  for  exogeneous 
fire  power 


FIGURE  B-3  SUBROUTINE  RANDM  BLOCK  DIAGRAM 


These  subroutines  are  called 
from  program  TSM01  in 
OVERLAY  2,3 


t 


SA-5822-5 


FIGURE  B-4  SUBROUTINE  TSMO  BLOCK  DIAGRAM 
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D029O  to  380 


■ 


Determine  minimum  time  to  next  descriptor  event  and  associated 
event  type  (NTC)  and  time  (DT)  for  Red  and  Blue 


INVBAT,  INVLB 

Compute  minimum  time  for  a unit  to  reach  the 
threshold  of  survival  for  homogeneous  (subroutine 
iNVBAT)  and  nonhomgeneous  (subroutine  INVLB) 
battles 


These  subroutines  are  called 
from  program  TSM03  in 
OVERLAY  2.  5 


398 J 

Increment  time  to  next  event  (TIME) 

Update  time  of  last  event  (BTA/RTA)  for 
each  interacting  unit  (i.e.,  to  reflect 
BATTLE/LINBAT  computations) 


100,  D0180,  188.  D025O 


Update  unit  status,  location,  objective  for  units  waiting, 
completing  moves,  being  deployed,  and  reaching  objectives 
Process  side  which  caused  last  event,  then  the 
other  side 


SA-5822-5e 


BATTLE.  LINBAT 

Given  minimum  time  to  next  event  DT,  compute  attrition  at  each  node 
and  reduce  order  of  battle  for  homogeneous  (BATTLE)  and 
nonhomogeneous  (LINBAT)  interactions 
Accumulate  attrition  by  unit 
Write  node  summary  In  battle  history  If  required 


FIGURE  B-4  SUBROUTINE  TSMO  BLOCK  DIAGRAM  (Concluded) 
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0020,  0024 


Sum  Blue  and  Red: 

Order  of  battle  (BTRUP/RTRUP) 

Normalized  order  of  battle  (BAW/RAW) 
Normalized  exogenous  effectiveness  (BFPA/RFPA) 
Exogenous  effectiveness  (BFPAA/RFPAA) 

Save  unit  indexes  (BU/RU) 


r V 

Number  of  Blue  or  Red  units 
ANO  normalized  exogenous 
effectiveness  equal  07 


Blue  and  Red 
present  at  node? 


y~] 


Both  Blue  and  Red 
present  at  node 


Either  no  Blue 
or  no  Red 
present  at  node 


SA-5822-9 


FIGURE  B-5  SUBROUTINE  BATTLE  BLOCK  DIAGRAM 
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© 


Both  Blue  and  Red 
present  at  node 


0 


Compute  normalization 

factors  for  linear  and 

Compute  normalization  factors 

mixsd  laws  IBNORM/RNORUI 

Normalize  order  of  battle  and 

Normalize  exogenous  firepower 

exogenous  effectiveness 

(BFPA/RFPA) 

Normalize  time  to  next  event  IT) 

according  to  fight  law 

Y« 

Square  law? 


Normah..*e  order  of  battle 
fBAW/RAW)  and  exogen 
ous  factors  (BFPA/RFPA) 


CALCML 


Compute  attrition  in  time  period 
that  is  due  to 

exogenous  fire  only  (BSV/RSV) 


CALCnn 


Solve  normalized  differential  fight  law 
equations  analytically  or  by  numerical 
methods  producing  total  normalized 
attrited  order  of  bettie  at  node  during 
time  DT 


29 


© 


Unnormalize  attrition 
according  to  fight  law  (BSV/RSV) 

/ Print  battle  history  output  / 

/ for  node  (If  required)  / 

D03O,  0031. 

' 0040,  0036 

Reduce  order  of  bi 
for  each  unit  at 
and  Red  units  ( 

Accumulate  attritit 
unit  (BILF/RIU 

ittle  proportiortally 
node  for  all  Blue 
3LU/RED) 

>n  by  attriting 

C 


> 


< 


Next  battle  type 


© 

© 


T 

^ END  ^ 


FIGURE  B-5  SUBROUTINE  BATTLE  BLOCK  DIAGRAM  (Concluded) 


SA-ss3:-ga 
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D01O.  00  14 


0020,  0024 


Sum  Blue  and  Red: 
order  of  battle  (BTRUP/RTRUP) 
normalized  order  of  battle  (BAW/RAW) 
normalized  exogenous  effectiveness  (BFPA/RFPA) 
exogenous  effectiveness  (BFPAA/RFPAA) 

Save  unit  indexes  (BU/RU) 


Number  of  Blue  or  Red  units 
ANO  normalized  exogenous 
effectiveness  equal  07 


0032,  0042 


Oetermine  Blue  and  Red  unit  closest 
to  threshold  of  SURVIVAL  and  compute 
ratio  of  threshold  to  order  of  battle 
IBS/RS) 


FIGURE  B-6  SUBROUTINE  INVBAT  BLOCK  DIAGRAM 
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0 


Both  Blue  and  Red 
present  at  node 


0 


250.  310 


Either  no  Blue  or  no  Red 
present  at  node 


Compute  normalization 

factors  for  linear  and 

Compute  normalization  factors 

mixed  laws  (6NORM/ 

Nornsalize  order  of  battle  and 

RNORM) 

exogenous  effectiver>ess 

Norntalize  exogenous 
firepower  (6FPA/BFPA) 

according  to  fight  law 

Square  law? 


> 


210,  220,  230 

Normaii2e  order  of  battle 
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FIGURE  B-6  SUBROUTINE  INVBAT  BLOCK  DIAGRAM  (Concluded) 
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Compute  indexes  to  node  (IN),  and 
number  of  Blue  and  Red  units  (K6/KR) 


00130,  001 70 

For  Blue  and  Red  units,  compute: 

Unit  index  (JB/JR) 

Order  of  battle  (X/Y) 

Unit  ordinal  on  BTLENODE  card  (KJB/KJR) 
Sum  of  exogenous  firepower  effectiveness 
on  unit  (C/0) 


Compute  matrices  of: 

Normalized  unit  attrition  coefficients  (A/B) 
Surveillance  effectiveness  coefficients  (ALP/BET) 


SA-5822-10 

FIGURE  B-7  SUBROUTINE  LINBAT  BLOCK  DIAGRAM 
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00300 


Subroutine 

INVLB 


Loop  on  BTLENODE,  non- 
homogenous  cards 


SA-5822>8 


FIGURE  B-8  SUBROUTINE  INVLB  BLOCK  DIAGRAM 
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FIGURE  B-9  SUBROUTINE  ADCP5  BLOCK  DIAGRAM 
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Appendix  C 

VARIABLE  DEFINITIONS 


The  information  content  of  variables  is  critical  to  understanding 
and  changing  the  features  of  a program.  A dictionary  of  the  variables 
in  each  COMMON  block  of  BALFRAM  has  been  assembled  and  updated  during 
this  research  and  is  included  in  this  appendix. 


The  BALFRAM  program  uses  numerous  dimensioned  variables  or  arrays 
to  store  input  data  and  intermediate  results.  Variables  are  assembled 
into  COMMON  blocks  according  to  their  usage.  Generally,  variables  asso- 
ciated with  a particular  descriptor  are  organized  into  the  same  COMMON 
block.  To  preserve  the  correspondence  of  variables  and  their  COMMON 
blocks,  the  variable  definitions  are  also  organized  by  COMMON  block.  All 
variables  in  each  COMMON  block  are  defined,  their  size  (DIMENSION)  given, 
and  the  source  of  the  data  is  provided  for  cross  reference.  Table  C-1  is 
an  alphabetical  guide  to  the  page  location  of  each  COMMON  block  definition. 


Table  C-2  provides  the  current  dimensions  allowed  for  each  descriptor 
type,  the  symbol  for  each  dimension  that  is  used  in  the  tables  in  this 
appendix,  and  the  COMMON  where  associated  data  is  stored.  The  remaining 
Tables  C-3  to  C-27  provide  the  definitions  of  the  variable  parameters 
for  each  COMMON.  The  data  origin  entry  specifies  the  source  of  the  data 
in  that  variable.  If  the  data  origin  is  a specific  field  on  one  of  the 
descriptor  cards,  refer  to  the  BALFRAM  User  Manual  for  further  informa- 
tion. If  the  entry  is  a subroutine  name,  refer  to  that  subroutine.  An 
entry  enclosed  in  parentheses  means  that  at  least  one  step  of  processing 
is  involved  between  the  source  shown  and  the  storage  array. 

This  appendix  should  replace  Appendix  D in  the  BALFRAM  Programmer 
Maintenance  Manual. 
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Table  C-1 


GUIDE  TO  COMMON  BLOCK  TABLES 


Common  Name 

Page  Number 

BLUE 

68 

CALCMC 

69 

DCMN 

69 

E 

70 

F 

73 

FB 

73 

FBA 

74 

G 

74 

H 

75 

L 

76 

LG 

77 

LSOLA 

77 

NLOG 

78 

OLll 

78 

OVL22 

79 

OVL23 

79 

OVL245 

79 

PATCH 

78 

PLAN56 

79 

PLN 

80 

R 

81 

RED 

81 

SUMRY 

82 

SUNIT 

TEMP 


82 

83 


Table  C-2 


DESCRIPTOR  DIMENSION  LIMITS 


Descriptor  Type 

Maximum  Dimension  Allowed 

COMMON  Block(s) 
in  Which  Used 

Number 

Name 

UNITSPEC 

120 

$NU 

BLUE, RED, DCMN 

NODEPROP 

80 

$NP 

E 

FRCRATIO 

6 

$FR 

F 

ADVANCE 

40 

$AD 

E 

RETREAT 

40,20 

$RT,$RT2 

E 

DSTRIBUT 

12,20 

$DR,$DR2 

H 

SUMMARY 

40,50 

$SM,$SM2 

SUMRY 

BTLENODE 

a.  Homogeneous 

50 

$BH 

CALCM 

b.  Nonhomogeneous 

10,20,20 

$BN,$BN2,$BN3 

L 

OBJCTADV 

40,20 

$OA,$OA2 

E 

NODATFAC 

20 

$NA 

E 

PROAS IGN 

20 

$PR 

G 

STRTEGRT 

40 

$SR 

G 

TIMEADV 

40 

$TA 

E 

RANDMSEQ 

20,30 

$RS,$RS2 

R 

SUMUNIT 

10,20 

$SU,$SU2 

SUNIT 

REDEPLOY 

10 

$RE,$RE2,$RE3 

E 

CHASE 

20 

$CH 

G 

RENDEVOU 

20 

$RV 

G 

EXOGUNIT 

40 

$EX2 

E 

OPEXOGUN 

10 

$OP 

E 

LGINTDIC 

5,20,20 

$LG,$LG2,$LG3 

LG 

PARMCHNG 

100 

$PC 

FB 

STOPBTLE 

5 

$ST 

E 

LINSOLU 

1 

— 

LSOLA 

Number  of  Nodes 

80 

$ND 

CALCM 

67 


68 


COMMON  BLOCK  "CALCMC"  ARRAYS 


1 


r 


Parameter  Meaning  Origin  Dimension 
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FPDFAC  (20)  I Exogenous  firepower  modifications  factor  I NODATFAC-4 


Table  C-6  (Concluded) 
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Table  C-8  (Concluded) 


COMMON  BLOCK  "L"  ARRAYS 


r — T 


•11 


76 


i 

j 


COMMON  BLOCK  "LG"  ARRAYS 


r 


T 


77 

L 


COMMON  BLOCK  "NLOG”  ARRAYS 


Number  of  nodes  read  from  NODH  file  Subroutine 


COMMON  BLOCK  "OVL22"  ARRAYS 


80 


r 

! 
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Table  C-24  (Concluded) 


ISMU  Number  of  SUMUNIT  cards  1 

-NSMUN  (10)  Unit  to  which  aggregated  parameter  is  to  be  assigned  SUMUNIT-3  SSU 

-NSMUC  (10)  Type  of  aggregation  code  (1  to  8)  SUMUNIT-4  $SII 

-NSMSUN  (10)  Number  of  units  to  be  aggregated  (neg.  If  RED)  SUMUNIT-5  $SU 

-NSMUNT  (10,10)  Identifiers  of  all  units  to  be  aggregated  (SUMUNIT-6ff . ) SSU  x NSMSUN 


ARRAYS 
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Appendix  D 

HALF RAM  DESCRIPTOR  OVERVIEW 


1.  INTRODUCTION 

Input  data  for  the  BALFRAM  program  consist  of  descriptor  cards  and 
card  sets.  This  appendix  is  included  to  provide  the  reader  who  is  un- 
familiar with  BALFRAM  a brief  overview  of  the  capabilities  of  each  de- 
scriptor. For  more  detailed  information  readers  are  referred  to  the 
User  Manual  and  the  Seminar  Guide. 

For  expository  purposes,  inputs  to  the  BALFRAM  program  (descriptors) 
have  been  organized  into  five  groups,  as  follows: 

• Program  control  instructions 

• Force  definition  inputs 

• Battle  logic  inputs 

• Movement  logic  inputs 

• Sensitivity  analysis  instructions. 

Each  group  of  descriptors  is  discussed  below. 


2.  PROGRAM  CONTROL  INSTRUCTIONS 

These  descriptors  specify  the  number  of  nodes  in  the  scenario,  the 
type  of  output  to  be  produced,  and  how  that  output  is  to  be  labeled. 


2. 1 Title  Card 


This  card  gives  the  scenario  title. 


2. 2 Program  Control  Card 

This  card  furnishes  information  to  the  program  concerning:  number 
of  nodes  used  to  generate  geographic  input,  selection  of  attrition  com- 
putation equations,  maximum  length  of  simulated  battle,  output  of  detailed 
battle  history,  elapsed  time  before  battle  history  output  is  started, 
source  of  geographic  input,  and  other  options  for  processing. 
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2.3  LINSOLU  Card 


This  is  an  optional  program  instruction  that  can  be  used  to  generate 
the  order  of  battle  or  number  of  forces  required  to  produce  a desired 
battle  outcome  where  the  desired  battle  outcome  is  stipulated  in  terms 
of  the  difference  between  surviving  BLUE  and  RED  forces. 

2.4  SUMMARY  Card  Set 

This  card  set  selects  and  labels  information  to  be  included  in  the 
battle  summary  output.  Use  of  this  card  set  is  optional,  but  if  no 
SUMMARY  card  set  is  input,  there  will  be  no  summary  printout. 

2.5  SUMTITLE  Card  Set 

This  card  set  provides  row  and  column  headings  when  battle  summary 
printout  is  in  matrix  form. 

2.6  END  Card 

This  card  signals  the  end  of  the  descriptor  set. 

3.  FORCE  DEFINITION  INPUTS 

These  descriptors  specify  the  sizes  and  capabilities  of  forces  and 
include  the  option  of  changing  force  characteristics  at  user-specified 
times  in  the  battle. 


3. 1  UNITSPEC  Card 


This  card  describes  the  size  and  capabilities  of  forces  involved 
in  the  scenario. 


3.2  GUERILLA  Card 

This  card  stipulates  the  conditions  under  which  the  various  units 
may  disengage  when  they  are  involved  in  a battle.  If  no  specific  disen- 
gagement rule  is  specified  for  a unit,  it  cannot  disengage  while  involved 
in  a battle. 


3.3  PARMCHNG  Card 

This  card  (and  its  variants  PVCHANGE,  UVCHANGE,  and  UNCHANGE) 
changes  the  value  of  certain  force  characteristics  at  specified  times 
during  the  scenario. 
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4. 


BATTLE  LOGIC  INPUTS 


These  descriptors  specify  where  battles  can  take  place  and  define 
additional  force  characteristics  that  are  specific  to  conditions  at 
those  locations. 


4. 1  BTLENODE- -Homogeneous  Card  Set 

This  card  set  describes  the  nodes  at  which  homogeneous  battles  may 
occur.  Homogeneous  battles  are  interactions  between  sets  of  units  of 
like  type,  e.g.,  BLUE  ground  forces  versus  RED  ground  forces.  Additional 
information  concerning  attrition  characteristics  for  BLUE  and  RED  and 
the  manner  in  which  the  attrition  is  to  be  calculated  are  also  input  with 
this  card  set. 


4 . 2  BTLENODE--Nonhomogeneous  Card  Set 

This  card  set  describes  nodes  at  which  nonhomogeneous  battles  may 
occur.  These  are  interactions  between  sets  of  units  which  are  not  neces- 
sarily of  like  type  and  whose  mutual  attrition  can  be  approximated  by 
the  differential  linear  law. 


4.3  STOPBTLE  Card 

This  card  causes  battles  to  cease  when  a set  of  designated  units 
fall  below  their  respective  defeat  criteria,  when  any  unit  of  a set 
reaches  its  objective,  or  when  a time  limit  is  exceeded. 


4.4  NODATFAC  Card  Set 


This  card  set  inputs  a tabular  set  of  ICC  adjustment  factors  that 
apply  under  stipulated  conditions  at  a specified  node.  This  card  set 
would  be  used  when  the  attrition  factors  for  BLUE  and  RED  input  on  the 
corresponding  BTLENODE  card  do  not  pertain  to  all  situations  that  may 
occur  at  that  node. 


4.5  NODEPROP  Card 


This  card  describes  interaction  between  units  of  unlike  type  through 
exogenous  firepower  and  specifies  the  effectiveness  of  exogenous  fire- 
power. It  may  also  be  used  to  substitute  expected  value  computations 
for  other  programmed  attrition  computations. 
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4.6  EXOGL'NIT  Card 

This  card  directs  the  exogenous  firepower  of  a unit  at  enemy  units 
which  share  the  firing  unit's  nodal  location. 


4.7  OPEXOGUN  Card 

This  card  directs  exogenous  firepower  of  a specified  unit  at  the 
location  of  a designated  enemy  unit. 


4.8  PROASIGN  Card  Set 

This  card  set  assigns  or  redistributes  available  forces  among  spe- 
cified units. 


4. 9  LGINTDIC  Card  Set 

This  card  set  describes  the  logistic  pipelines  of  the  scenario  and 
incr'rporates  the  effects  of  reduction  of  pipeline  capacity  as  a result 
of  interdiction.  Provision  is  made  for  pipeline  regeneration  rates, 
deployment  and  resupply  rate  factors,  and  locations  of  nodes  which  are 
to  be  supplied. 


5.  MOVEMENT  LOGIC  INPUTS 

These  descriptors  control  the  planned  and  contingent  movements  of 
units  in  the  scenario.  Contingent  movements  are  determined  by  deployments 
and  events  that  occur  during  the  battles. 


5. 1  ADVANCE  Card 

This  card  moves  units  from  one  node  to  another  contingent  upon  the 
arrival  of  designated  forces  at  a third  node. 


5,2  RETREAT  Card 

This  card  moves  units  from  one  node  to  another,  contingent  upon 
designated  forces  no  longer  being  at  a third  node. 


5.3  OBJCTADV  Card 

This  card  relocates  specified  units  when  enemy  forces  at  the  des- 
ignated unit's  present  node  are  defeated  or  depart.  However,  if  enemy 
units  subsequently  occupy  the  node  from  which  the  units  have  advanced, 
the  friendly  units  return  to  this  node. 
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5.4  STRTEGRT  Card 


This  card  withdraws  units  when  the  casualty-inflicting  power  ratio 
of  the  enemy  to  friendly  forces  is  unfavorable.  "Unfavorable"  is  also 
a quantitatively  defined  user  input. 


5.5  TIME AD VN  Card 

This  card  relocates  units  at  stipulated  times. 


5.6  CHASE  Card 


This  card  causes  one  force  to  track  another.  The  CHASE  instruction 
can  be  implemented  as  a function  of  the  location  of  friendly  or  enemy 
forces,  the  destruction  of  friendly  or  enemy  forces,  or  the  ratio  of  the 
casualty-inflicting  power  of  friendly  to  enemy  units  at  a designated  node. 


5.7  RENDEVOU  Card 


This  card  is  similar  to  the  CHASE  card  in  that  it  causes  a sequen- 
tial link-up  of  forces.  However,  unlike  the  CHASE  card,  which  is  used 
to  track  or  link-up  forces  of  opposing  sides,  the  RENDEVOU  card  links 
forces  of  the  same  side.  The  criteria  for  implementing  the  RENDEVOU 
instruction  are  identical  to  those  for  the  CHASE  card. 


5.8  REDEPLOY  Card  Set 

This  card  set  redeploys  designated  units  after  a battle  has  been 
won.  It  also  includes  a provision  for  holding  redeployed  forces  at  a 
staging  area  for  retrofit  prior  to  redeployment. 


5.9  FEBAMOVE  Card  Set 


This  card  set  resets  unit  mobility  factors  on  the  basis  of  the  force 
ratio  of  the  two  opposing  forces  to  reflect  alternate  movement  rates  at 
the  Forward  Edge  of  Battle  Area  (FEBA)  during  the  course  of  a battle. 


6.  SENSITIVITY  ANALYSIS  INSTRUCTIONS 

These  descriptors  control  the  changes  in  scenario  parameters  that 
are  made  between  automatic,  repetitive  iterations  in  order  to  provide 
output  for  use  in  sensitivity  and  game  theoretic  analyses. 
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6. 1 FRCRATIO  Card 

This  card  multiplies  Che  order  of  battle,  the  index  of  combat  effec- 
tiveness, or  the  exogenous  firepower  of  units  by  specified  factors. 

6.2  DSTRIBUT  Card 

This  card  allocates  progressively  larger  percentages  of  forces  from 
one  group  of  units  to  another  group  of  units. 

6.3  RANDMSEQ  Card  Set 

This  card  set  generates  parameter  sensitivity  studies  and  allows 
certain  parameters  to  be  input  as  a normal  distribution. 
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Appendix  E 

TACTICAL  PROBLEMS  IN  MAN -COMPUTER  INTERFACE 


Appendix  E 


TACTICAL  PROBLEMS  IN  MAN-COMPUTER  INTERACTIVE  MODELS 


1.  INTRODUCTION 

Just  a short  time  ago,  a paper  of  this  nature  would  not  be  consid- 
ered suitable  for  an  audience  composed  primarily  of  senior-level  experts 
in  military  gaming.  The  subjects  discussed  here  would  probably  be  clas- 
sified as  simply  computer  programming  problems  that  could  be  solved  by 
programmers  or  technicians.  But  experience  has  taught  us  otherwise. 
Indeed,  very  often  the  failure  to  solve  a tactical  problem  can  prevent 
the  realization  of  important  innovations  or  breakthroughs  of  more  theo- 
retical types.  As  a simple  example,  linear  programming  applications 
became  possible  only  because  of  the  availability  of  sophisticated  computer 
hardware  and  software. 

During  this  conference,  speakers  have  been  mentioning  the  need  for 
man-computer  interactive  gaming,  which  is  also  called  "man-in-the- 
loop"  gaming.  This  paper  addresses  some  <"actical  problems  that  seem  to 
be  common  to  a number  of  man-computer  interactive  gaming  models.  These 
tactical  problems  involve  some  nonmilitary  man-computer  models,  because, 
from  a modeling  point-of-view,  they  are  very  similar  to  military  gaming 
models. 

The  term  "interactive  gaming"  means  computer-based  gaming  in  which 
the  users  or  operators  may  interject  their  decisions  on-line  through  a 
remote  terminal  in  a cooperative  manner  with  the  computer.  It  is  not 
required  that  all  the  input  data  be  submitted  to  the  computer  at  the 
outset  of  the  game  because  a simulation  run  can  take  only  a single  path 
from  start  to  finish.  It  is  not  necessary,  then,  that  contingency  logic 
be  supplied  at  every  decision  node.  For  this  process,  the  amount  of 
input,  which  otherwise  would  be  required  in  conventional  gaming,  can  be 
greatly  reduced.  If  each  game  process  is  viewed  as  a path  in  a decision 
tree,  the  nodes  that  would  require  data  input  are  shown  in  Figure  E-1 
as  solid  circles.  In  a non-interative  process,  all  the  nodes  would  re- 
quire input  data  based  on  the  chance  that  any  path  might  be  taken. 


This  appendix  documents  a paper  given  at  the  Theater-Level  Gaming  and 
Analysis  Workshop,  Leesburg,  Virginia  on  29  September  1977  by  Dr.  Paul 
L.  Tuan.  The  Workshop  was  sponsored  by  the  Office  of  Naval  Research. 
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FIGURE  E-1  A DECISION  TREE  SHOWING  SINGLE  PATH  VERSUS  MULTIPLE  OUTCOMES 


i 


To  use  BALFRAM  (Balanced  Force  Requirements  Analysis  Model)  as  an 
' example,  we  envision  a typical  interactive  process  such  as  shown  in 

I Figure  E-2.  The  points  in  the  interactive  simulation  process  of  man- 

[ computer  interface  are  highlighted.  In  general,  at  these  points  the  man 

I furnishes  a list  of  data  or  simulation  parameters  used  to  control  the 

^ next  steps  in  the  simulation. 

The  BALFRAM  proj.ect  is  currently  sponsored  by  the  Fleet  Analysis  and 
Support  Division  (Code  230)  of  the  Office  of  Naval  Research,  and  we  are 
now  at  the  beginning  of  the  second  phase  of  interactive  design.  BALFRAM 
is  currently  used  by  CINCPAC  and  its  subordinate  commands  as  a theater- 
level  gaming  tool  for  analyzing  JSOP  or  JSOP-related  plans.  Because  of 
its  flexibility  in  accepting  user-designed  contingency  logic  and  different 
levels  of  data  aggregation,  BALFRAM  has  a built-in  advantage  for  easy 
adaptation  to  man-computer  interactive  process. 

' In  the  course  of  designing  and  implementing  an  interactive  type  of 

I system,  often  we  encounter  the  following  problems: 

I 

• Levels  of  human  control 

• Human  judgment  versus  algorithmic  judgment 

• Decomposition  schemes 

• Computer  information  filtering  and  distribution 

• Human  factor  problems. 

These  problems  are  not  all  inclusive,  nor  do  they  necessarily  represent 
all  of  the  most  important  problems  in  man-computer  interactive  design. 

Only  a few  significant  problems  are  presented  to  .show  the  type  and  scope 
of  problems  encountered. 


2.  LEVELS  OF  HUMAN  CONTROL 

Generally,  there  are  two  levels  of  human  control  that  should  be 
designed  into  an  interactive  process--the  macrolevel  and  the  microlevel. 
The  macrolevel  can  also  be  called  the  "parametric  level,"  and  the  micro- 
level can  be  called  the  "heuristics  level."  At  the  parametric  level, 
the  process  remains  essentially  model-driven,  but  the  operator  may  select 
and  adjust  certain  parameter  values  or  functions.  For  example,  the 
operator  may:  change  certain  coefficient  values  in  the  objective  func- 
tion; select  an  alternative  objective  function;  change  on  a probability 
! function  or  its  parameters;  replace  Lanchester  equations  with  arbitrary 

I functions.  The  influence  of  such  control  is  global. 

1 

. At  the  microlevel  or  heuristics  level,  the  human  operator  may  make 

specific  decisions  at  certain  decision  points  in  a subjective  manner. 

• At  this  level,  the  operator  may  decide  what  percentage  of  the  available 

air  power  should  a specific  unit  commit  to  close  air  support  (CAS)  at  a 
’ particular  node  or  whether  a red  ground  force  unit  should  be  considered 

viable  for  further  combat.  These  decisions  will  be  made  by  an  on-line 
I 
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evaluation  of  the  battle  conditions  at  the  decision  point  rather  than 
using  predetermined  decision  criteria. 

In  designing  and  implementing  this  two- level  approach,  we  have  used 
two  basic  design  methods.  The  first  approach  divides  the  macrolevels  and 
microlevels  into  two  independent  stages  as  shown  in  Figure  E-3.  The  first 
stage  is  designed  for  macrolevel  control  in  which  the  operator  may  change 
control  parameters  and  run  the  simulation  on-line  from  the  CRT  iteratively. 
When  no  more  improvements  can  be  made  at  the  macrolevel,  then  the  operator 
will  enter. the  next  stage  and  make  arbitrary  and  subjective  decisions. 

The  model,  at  this  stage,  would  only  serve  as  a referee  and  bookkeeper 
and  would  not  attempt  to  conduct  optimization  procedures.  Also,  under 
this  approach,  once  the  process  enters  stage  2,  it  cannot  return  to  stage 
1 without  forfeiting  the  changes  made  by  the  operator  during  stage  2. 

The  second  approach  is  more  flexible  in  mixing  the  macrolevels  and 
microlevels.  Figure  E-4  depicts  a system  in  which  the  normal  control  is 
automatic,  but  in  which  the  operator  can  interrupt  the  decision  loop  at 
two  points  to  make  subjective  decisions.  This  system  is  capable  of 
returning  to  automatic  model  control  after  each  interruption. 

It  is  not  clear  that  either  of  these  approaches  has  a distinct  ad- 
vantage. The  first  approach  is  generally  less  costly  to  design  because 
the  two  stages  are  segregated  and  no  recycling  is  allowed.  The  second 
approach  offers  a greater  flexibility  for  man-computer  interaction. 


3.  HUMAN  JUDGMENT  VERSUS  ALGORITHMIC  JUDGMENT 

There  can  be  a problem  when  an  operator  must  interface  with  a com- 
plex model  that  handles  many  parameters.  Interface  requirements  must  be 
specified  and  the  operator  decisions  must  be  compatible  with  the  algo- 
rithmic decisions  (or  vice  versa).  For  example,  if  a model  uses  an  inter- 
active procedure  for  reaching  an  optimum,  what  would  happen  to  the  final 
solution  when  an  intermediate  value,  which  is  a result  of  automatic  com- 
putations, is  replaced  by  a heuristically  generated  value?  Would  the 
computations  become  unstable?  Part  of  the  answer  is  in  the  proper  design 
of  filters  and  software  controls  so  that  the  operator  input  cannot  vio- 
late the  designed  algorithm  objectives.  Another  part  of  the  answer  is 
in  the  method  of  decomposition,  or  partitioning  of  the  model  functions. 

If  the  interactive  process  is  decomposed  properly,  the  conflict  between 
human  judgment  and  algorithmic  judgment  can  be  avoided. 


4.  DECOMPOSITION  SCHEMES 

Unlike  mathematical  programming,  the  decomposition  scheme  in  a man- 
computer  interactive  simulation  process  does  not  always  lend  itself  to 
precisely  defined  terms.  The  most  common  means  of  partitioning  an  inter- 
active process  are  by: 
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FIGURE  E-4  INTERACTIVE  PROCESS  COMBINING  THE  MACROLEVEL  AND 
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Decomposition  by  geographical  partition  can  be  done  easily  as  long 
as  the  resultant  subgraphs  are  not  interrelated  in  such  a way  that  they 
have  overlapping  activities  at  the  boundaries.  Decomposition  by  levels- 
of-aggregation  is  a very  worthwhile  proposition  because  the  model  is  more 
responsive  to  user  requirements  for  data  resolution  and  the  user  cost 
for  data  acquisition. 

Our  current  effort  on  several  man-computer  projects  is  centered  around 
a combination  of  time  and  decision  hierarchy  partitions.  Figure  E-5 
shows  a straightforward  sequential  simulation  in  which  the  gaming  process 
within  each  stage  can  be  executed  without  having  to  be  concerned  about 
other  stages.  Figure  E-6  shows  a more  involved  man-computer  simulation 
in  which  the  process  can  be  recycled  to  previous  stages.  The  method  shown 
in  Figure  E-6  requires  more  sophisticated  software  and  terminal  display 
capabilities. 

5.  COMPUTER  INFORMATION  FILTERING  AND  DISTRIBUTION 

Most  of  the  theater-level  games  are  currently  supported  by  large 
computers  that  are  not  designed  for  distributed  information  processing. 
Performing  remote  on-line  interactive  gaming  with  these  computer  systems 
would  not  be  realistic  because  of  the  high  cost  of  real-time  processing 
in  a multiprogram  environment. 

With  the  advent  of  low-cost  microprocessors  and  graphics  CRT  ter- 
minals, games  could  be  played  at  intelligent  (interactive)  terminals  with 
only  occasional  communication  with  the  main-frame  computer.  Much  of  the 
map  composition,  input/output  data  editing  and  formatting,  instructions 
to  operators,  and  even  some  simple  gaming  logic  can  be  done  at  the  local 
terminal  (see  Figure  E-7).  The  communication  between  the  local  terminal 
and  the  main-frame  computer  can  be  on  a batch  basis,  which  would  signif- 
icantly reduce  processing  cost.  The  determination  of  what  and  how  much 
information  is  to  be  transmitted  back  and  forth  is  a design  task  that 
should  be  studied  in  depth,  then  carefully  specified. 

6.  HUMAN  FACTOR  PROBLEMS 

Often  the  tasks  of  CRT  formatting  such  as  color  selection  (if  color 
CRT  is  to  be  used),  keyboard  arrangement,  and  graphics  generation,  are 
left  to  the  programmers  as  the  last  stage  of  the  design  phase.  If  an 
interactive  tool  is  to  be  introduced  to  decision-makers  the  console  en- 
vironment must  be  designed  to  meet  the  needs  of  noncomputer  personnel  and 
not  solely  for  professional  programmers  or  operators.  The  problems  of 
console  management,  reaction  time,  perfomiance  feedbacks,  stress  factors, 
human  cognitive  process,  and  CRT  screen  formatting,  and  the  like,  should 
have  high  priority  design  and  implementation  status. 


• Time  division 

• Geographical  partition 

• Hierarchical  structure  of  decision-making 

• Levels  of  aggregation. 
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FIGURE  E-5  SEQUENTIAL  SIMULATION 
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FIGURE  E-6  RECYCLING  SIMULATION 


FIGURE  E-7  A DISTRIBUTED  SIMULATION  PROCESS 
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